Track this topic | Email this topic | Print this topic

*takes hat off* i applaud you sir. you must have far superior programing skills than me. although i find 3d work, factoring and crossfactoring, and graphics implementation quite easy, i am horrible at coding, mechanincs, and calculations.

as always, good luck to you. ill be checking in often to see your progress.

--------------------

"Life: The deepest cut that wilt not heal. Fore it bleeds on and on as if an eternity. An endless river of blood in which death is thyne only escape. And as the tainted years pass, that escape muddles us with temptation."

Thank you for the kind words, but really I don't think I'm anything special-- I'm just a person with too much time^^

I hope my progress will keep you interested enough to keep coming back! ^_^v

Uh... how can the "3D math" be hard?

Unless you're writing your own 3D API, modern graphic libraries that support 3D take care of 99.9% of the calculations for you. Why reinvent the wheel and waste time and effort by not taking advantage of what's already there?

The hardest stuff that isn't handled by graphic libs (but should be handled by any decent game engine, which WOULD be the point of using a pre-made one) are pretty much just depth-sorting algorithms and polygone intersections (which aren't really necessary; you can just use a bounding sphere to achieve more than acceptable collision detection, really...)

The rest would be graphic effects that require little to no actual 3D math: pixel shaders come to mind. Vertex shades too, which is about as 3D-math-ish as it gets.

If you have to work out the nitty-gritty code to handle 3D math, you should consider getting a better game engine or reading up a little on the API you're using. :/

--------------------

"Judge not a man by his thoughts and words, but by
the quality and quantity of liquor in his possession
and the likelyhood of him sharing."

I didn't say the 3D math actually _IS_ hard, it's just harder than the internal calculations that were mentioned earlier for stats and whatnot.

As far as the 3D math that needs to be used by me, some simple examples (based on what I'm working on right now, which is cameras) would be:

A camera that orbits around the character. Right there, you need some simple trig to make it have a constant distance from the character. Nothing special- unit circle + right angle triangle trig is fine.

Having a character strafe related to the direction the camera is facing, crossproduct calculation there.

Testing for visiblity of the character (ie, no hills between the character and the camera) requires casting a Ray from a specific position in the camera's viewport (in this case, center) towards the character's 3d position, testing for collisions with terrain/the character, and checking which is less (ie, which the Ray hit first).

I'm sure you know this already, as your game is 3D, but just to reiterate (and let those who don't know, know), everything is in 3d space, meaning as soon as anything moves, -TECHNICALLY- there's 3d math involved.

Not to be rude, but I find it kind of surprising that you think there's very little 3d math involved in programming a 3d game.... ?_?

Also take note (and I _THINK_ I said this before, but I may not have, so forgive me...) that the engine I'm using is a _RENDERING_ engine only, not a full game engine. The -only- thing it takes care of is rendering the graphics that I pass to it. And actually, the depth-sorting algorithms (as far as transparency rendering, and a couple other things are concerned...) are handled by the engine already. Just check out www.ogre3d.org and read up on the features to get an idea of what the engine handles or not^^ It's a pretty powerful engine, especially for being free *dance*

Are you perhaps getting the definitions of different types of engines confused? You seem to use game engine and rendering engine interchangably, and seem to be including physics engine capabilities in the mix.. Forgive me if I'm misunderstanding...

<Edit>Wrong website- fixed now</Edit>

This post has been edited by nyxojaele on 19th February 2006 23:28

Quote

A camera that orbits around the character.  Right there, you need some simple trig to make it have a constant distance from the character.  Nothing special- unit circle + right angle triangle trig is fine.

Forgot which API you were using, but unless you need special camera handling gluLookAt() handles most of this already. The only "3D math" comes in the form of a trig function to handle camera rotations around an arbitrary point in 3D space (nothing too complex, really.)

Quote

Having a character strafe related to the direction the camera is facing, crossproduct calculation there.

Indeed, but is strafing really necessary in an RPG? Mind you, yes, it does involve something a little more complex than "x = x + 1.0f; //whee, I'm movingz lolz" but strafing sounds a little much in terms of movement... Well, at least there's no jumping involved.

Quote

Testing for visiblity of the character (ie, no hills between the character and the camera) requires casting a Ray from a specific position in the camera's viewport (in this case, center) towards the character's 3d position, testing for collisions with terrain/the character, and checking which is less (ie, which the Ray hit first).

OpenGL 1.5 and DirectX 9 allow an occlusion query, which handles this in hardware. This allows you to test an object's bounding box/sphere/mesh and either reject it or display it depending on occlusion conditions.

http://www.gamedev.net/reference/programmi...clusionculling/

This should help. Haven't given it more than a brief glance but it seems to explain it well enough for DirectX.

Quote

I'm sure you know this already, as your game is 3D, but just to reiterate (and let those who don't know, know), everything is in 3d space, meaning as soon as anything moves, -TECHNICALLY- there's 3d math involved.

You'd just need to move in 2D space and manipulate a heightmap. This is probably the most complicated bit of 3D math (though nothing too complicated, all things considered): finding which polygone you're standing on, and finding your height along it using its points as reference. Splitting up your map into sectors allows for overlapping heights easily enough.

Decent organization would avoid a lot of work. You could, for instance, map polies to a grid to cull the amount of polies to test considerably (ie, find the cell you're in via your x/y position, then test the polygones in it to see which you're standing on.)

An extremely intricate map with many overlapping regions would require more advanced techniques, but this is an RPG. And unless you're throwing in very in-depth modifications to the maps, I don't see how anything overcomplexified would be required.

Quote

Not to be rude, but I find it kind of surprising that you think there's very little 3d math involved in programming a 3d game.... ?_?

I just try to make the most of my APIs. The whole point of a library is to avoid having to reinvent the wheel, and if my library or hardware can do the work for me, I'm not going to attempt to reinvent something.

Of course, this can't always be avoided, and yes, there IS some 3D math involved. Just nothing that should caused enough of a problem to grind developement down for any period of time...

Quote

Also take note (and I _THINK_ I said this before, but I may not have, so forgive me...) that the engine I'm using is a _RENDERING_ engine only, not a full game engine.

Oh. Well, I take back a few things then; this takes care of some basic things but various game-related code would still require being implemented, yeah. Still, there's often something already written to take care of these things; unless you're supporting really low-end cards which don't have this built-in and have to emulate it in software, I don't see why you wouldn't take advantage of what's already out there.

Quote

It's a pretty powerful engine, especially for being free  *dance*

A rare blessing, nowadays...

--------------------

"Judge not a man by his thoughts and words, but by
the quality and quantity of liquor in his possession
and the likelyhood of him sharing."

Quote

Forgot which API you were using, but unless you need special camera handling gluLookAt() handles most of this already. The only "3D math" comes in the form of a trig function to handle camera rotations around an arbitrary point in 3D space (nothing too complex, really.)

The Ogre engine handles both DirectX and OpenGL, and has a single function to handle "lookAt" functions, which I use. And yes, I was referring to the trig functions required to handle the actual camera positions around that arbitrary point.

Quote

Indeed, but is strafing really necessary in an RPG? Mind you, yes, it does involve something a little more complex than "x = x + 1.0f; //whee, I'm movingz lolz" but strafing sounds a little much in terms of movement... Well, at least there's no jumping involved.

There's not much point in a game being remade into 3d if you can't appreciate some of the nicer effects of ... 3d-ness. heh^^ So currently I have 2 camera modes available to the player on the world map: "classic" top down, and a "3rd person" ala world of warcraft. In the 3rd person camera mode, obviously, strafing is the movement mode of choice (although other movement modes are available, and the keys are rebindable...) Yah, no jumping, hehe-- that would break a little bit of my code I threw together quickly to bind everything to the terrain (essentially making all movement on the map a 2d ordeal instead of 3d... ~whew~)

Quote

OpenGL 1.5 and DirectX 9 allow an occlusion query, which handles this in hardware. This allows you to test an object's bounding box/sphere/mesh and either reject it or display it depending on occlusion conditions.

http://www.gamedev.net/reference/programmi...clusionculling/

This should help. Haven't given it more than a brief glance but it seems to explain it well enough for DirectX.

Hey, useful bit of information- I found that a good read. I wasn't aware of that function in DirectX (but I'm not surprised since I'm an OpenGL fan...). I'm sure that would be incredibly useful, the only problem being (and this is my fault for not informing you of this originally...) that I'm actually not testing for visibility of the -character-, but rather of the character's "heading" (that is, a distance shortly in front of the character... which is where the camera is -actually- pointing), so in some situations, the character -could- be fully occluded, and that would be fine, so long as the point we're looking at is visible. Now I'd assume then that I could just make an occlusion mesh at the point we're looking at, and testing for that, but then that kinda ruins most of the point of having a rendering engine: You shouldn't have to deal directly with the APIs. Regardless, the ogre engine has the ray query there for a reason, and it'll work just fine-- but I'm going to ask the devs of Ogre if an occlusion function is in the works that implements the bit in that link you posted.

Quote

Decent organization would avoid a lot of work. You could, for instance, map polies to a grid to cull the amount of polies to test considerably (ie, find the cell you're in via your x/y position, then test the polygones in it to see which you're standing on.)

An extremely intricate map with many overlapping regions would require more advanced techniques, but this is an RPG. And unless you're throwing in very in-depth modifications to the maps, I don't see how anything overcomplexified would be required.

Nope, not changing the maps' layout at all, just making them 3D^^ I don't see any reason to be iterating thru -any- polies anywhere when testing for height on a 3D heightmap-- a simple rayquery straight down, and testing where it collides with the terrain is sufficient. 3D math for a 3D game *wink*

Quote

I just try to make the most of my APIs. The whole point of a library is to avoid having to reinvent the wheel, and if my library or hardware can do the work for me, I'm not going to attempt to reinvent something.

Of course, this can't always be avoided, and yes, there IS some 3D math involved. Just nothing that should caused enough of a problem to grind developement down for any period of time...

As do I, and from what I can see, I'm not "reinventing" anything that's already available to me thru Ogre. Just because Ogre has a different way of allowing something to be done doesn't necessarilly mean that I'm "reinventing" anything by using it :S

Heh- and nobody ever said that the 3D math was slowing anything down in any significant form-- I was merely using the 3D math as a comparison to the simple math mentioned earlier!

No doubt though, comparing engine mechanics to game mechanics is pretty ridiculous. The level of complexity between figuring out how much HP a character gains per level is very little compared to trackball-style camera rotations around an arbitrary point in 3D space.

Especially considering every aspect of FF6's mechanics have been pried apart by ROM hackers, but that's a moot point...

--------------------

"Judge not a man by his thoughts and words, but by
the quality and quantity of liquor in his possession
and the likelyhood of him sharing."

Yah, that's exactly the point I was making. Good thing it took us half a page of longwinded posts for us to end up back where we started hehe v

ps. To all you ROM hackers out there who've exposed the mathematics of FFVI: I LOVE YOU!

@SilverLance:
I just wanted to point out that I'm finding it interesting following what you're doing in your project, thru your website, whilst I'm going thru mine. It lets me view things a little differently, especially since you're doing a sprite based system, as opposed to my mesh based system.

This post has been edited by nyxojaele on 20th February 2006 02:39

Wow.... I deffinatly hope you finish.... It looks really good. Good luck... and hope you finish

So as many of your know a whole schwack of us have been having issues with connecting to CoN, unfortunately. I, obviously, am one of said individuals, and as such I've been unable to respond to much of anything here. Although it seems that there really isn't much to respond to in this thread as of right now. This possibly being because of the connection issues.

Anyways, I wanted to take this chance I have (5 minute window before I can't connect again!) to update people on the status of the project, and ask a question.

Update: _HUGE_ codebreaking bugs have prevented much progress in the past week or so-- I'd broken almost the entire program trying to track them down, and hopefully have them squashed now, so things should be back up and running tonite, if all goes well.

Yah, not much to read, but it's an update, nonetheless.

Anyways, question time: Is there enough interest (ie. is it worth my while..) in a continued progress update on this project, with new screenshots, maybe commentary on stuff and how it works in game, and what I'm currently doing/planning on doing soon, or would I be wasting my time? Let me know what you think/want to hear/see!

Actually, I'm pretty impressed. I'm REALLY hoping for you to finish this. I mean, that would be superlative.

What do you suppose the ETA would be? I imagine we're going in years.

--------------------

If you've been mod-o-fied,
It's an illusion, and you're in-between.
Don't you be tarot-fied,
It's just alot of nothing, so what can it mean?
~Frank Zappa

Sins exist only for people who are on the Way or approaching the Way

Honestly, I haven't a clue. I've never actually attempted a project this grande in scale before, so I haven't the foggiest what to expect. But seeing as this is a "in my free time" sorta deal, I think your guess could quite likely be assumed.

On that note tho, take into account that the amount of time it takes is directly proportional to how much of the content I actually put in, as well. That is, if I decide just to do everything up to finding the frozen esper at the beginning, it'll take a significantly lesser amount of time than, say, fighting right up thru super kefka..

As for an ETA on having something -playable-, I can't give you anything definate, but I can tell you what I'm _HOPING_ for, heh... Judging from my current rate of progress, I'm hoping to have something functional and playable before the summer (and that's giving me time to screw up, which I know I'll do^^), which would also include -some- content for the area(s) covered in game, but most likely not ALL content. Hell, it'll probably be more accurately described as "barely any", hehe^^;

Even if you just get up to the point where Biggs and Wedge get fried by Tritoch, I'll be happy

--------------------

OSonic Rave
/ \Last Arcanum
[ ]Strike Raid
XRagnarok

AAAH! Too much tech talk! *skims over most of it*

I really must applaud what you're attempting to do, nyxojaele, not so much for the idea, but for the fact that you actually know what you're doing, and are actually committed to following through (on at least a part of the game). You wouldn't believe how many people there are that start something like this, then quickly give up because they don't have the skills or they got bored. Now, I'm no programmer, but I could help with other things if you want. I don't know, mabe the script (you could rewrite it to flesh out the characters more) or music, as those are my strong points.

But mostly, I just wanted to wish you good luck on your project, and yes, there is most certainly enough interest to warrant continued information.

--------------------

The island bathes in the sun's bright rays
Distant hills wear a shroud of grey
A lonely breeze whispers in the trees
Sole witness to history

ICO-You were there-

I actually have no intention of changing the script, although I may go with something more accurately translated. I'm also toying with the idea of having an option for the player to see the original script from FFIII, a more accurately translated version, or the Japanese version. I -definately- want the option for the Japanese version, at least. On the translation: I'm not sure if I'll go with that controvesial "accurate" translation that was released on the net, or if I'll just translate it myself.. 'course, if I translate it myself, it'll probably end up being like that "accurate" one, so I'm kinda leaning towards that, with my own changes here and there as I warrant fit.

On the music front, I already said that I have fairly serious plans to incorporate the symphonic versions of the songs, where I can.. But thank you muchly for the offer! It's nice to know there's people out there who're interested in contributing, even tho I really don't know if/when I'll ever be accepting them^^

I think a lot of the people who attempt something like this have the problem of "biting off more than they can chew", and kinda burn out because of it. I figure if I put it into a bit more perspective, and take little bite-sized chunks, it's a much more plausible idea. Once I achieve one goal, I can always work towards another-- knowing already that I've exceeded my previous expectations^^ I could be wrong, but that's my $0.02 (don't spend it all in one place!)

Wow! Quite the lofty undertaking. Good luck with that. If it weren't for the fact that my programming skills can barely create and input text box I'd offer my services, but since I suck so much when it comes to programming (too bad....I wish I were good at it), I'll just say again, Good Luck!

FFVI 3D?
1 word: Amazing!

--------------------

It takes 2 people and a weapon
to commit a murder

Yesterday is history, Tomorrow is mystery,
today is a gift, thats why we call it the present.

Big update!

I just got QuakeIII level loading working! Now I'll be creating towns, and battle terrains using a QuakeIII level editor. Full support for the QuakeIII .shader scripts (which means all sorts of possibilities for animated textures!)

Attached is a couple of screenshots of some of the official QuakeIII maps, loaded into the game. Once I have something done, I'll post some shots of some preliminary Town/Battle scenes for more eye-candy. For now: enjoy the QuakeIII-y goodness!







The shaders need a little bit of tweaking and such (some scroll too fast, etc..) but the effect is there!

Also note that since imageshack allows for up to 1MB files, I'll be posting fullsized shots of my dev window (1024 x 768) from now on. So beware, modem users!

Well, that's it for the latest update! Now I'm off to fix some bugs, create a bit of content, and the next big step'll probably be integrating sound! (I currently have my eyes on the FMod engine, for those interested...)

Yay! I deffinatly can't wait now. Those look sweet. (too futuristic though.) Still looks cool. Good luck, and hope you finish!

Quote

finalfantasygirl:

Those look sweet. (too futuristic though.)

Didn't you read his post?

Quote

nyxojaele:

Attached is a couple of screenshots of some of the official QuakeIII maps

Anyway, good luck mate. Hope you don't bite off too much or you might suffocate. (It happens). Keep us updated, as I can't wait to see what else you have done.

--------------------

The frosty one.

Actually, I did read it, but, I didn't read it well. Lol...

Hey all-- it's been a while since I've posted here, so this is mostly just to let you all know that everything is alive and well. I'd been unable to dedicate massive amounts of time towards this in the past week or so, but progress is still being made.

Mostly, as of late, I've been (re)doing a lot of the background work of the game... stuff that isn't immediately, if at all, noticable to the player.

I've rebuilt the input stack to allow the game to handle more input states (keyup, keydown, keystilldown, etc..) Should've done that at the start, but at the time, I just wanted something functional.

I've also almost finished recoding the loading bar setup to properly reflect everything [virtually] that's being loaded. Until now, all the world data wasn't being shown in the loading bars. I've also put in place the framework to allow me to throw in the "advanced loading bar" that I've been planning for a while now. It'll be a purely aesthetic option that the player can set, to give them all sorts of fun data (and different graphics!) for the loading bar, instead of the normal "Here's a bar- watch it move!" mode.

Fixing lots of bugs (well, more like rudimentary features that weren't implemented yet...) in the world map mode. Even tho this portion is -technically- working correctly, it's kinda funny to walk around the world right now because the character's animation is a LOT slower than it moves, so Terra looks like she's rollerblading over the hills and whatnot^^

I also went thru and did an overhaul on most of the graphics that I'm 95.3% sure I'll be keeping (mostly GUI stuff), and now it looks a lot crisper and cleaner (read: sexier).

Been toying with some concept art to help decide ultimately what "style" I want the game to have (most specifically, how the characters will look...)

I've dropped the idea of using Quake3 maps for towns, as the visibility information wouldn't work very well AT ALL like that, which would result in -horrible- framerates in town. I'm about 75% sure I'll be keeping the Quake3 map format for the battle sequences tho, as the visibility information works fine for that situation. I've decided, at least tentatively, on using a compiled dotScene format (a compiled version of a common XML based format that many 3d modelling programs can output to), and I've given up on MS3D altogether for a better alternative: Blender. (I -highly- recommend this wonderful program to all bargain-bin 3d modellers out there!)

I've also implemented a rudimentary sky. Very simple, currently. All I did was map a fisheye sky image to a hemishere skydome. I'll worry about fancy stuff later. Just got sick of that blue/green.


Soon to be added list:
Sound & Music (this is my next major step, likely)

Collision detection & infinitization on the world map (you won't be able to run up mountains anymore, and the world map will loop, just like in the original game)

Background loading (this will hopefully eliminate any (or at least, 99% of them... depends on the situation..) of the loading screens that currently exist when entering a battle state. This'll give the player more of the classic "oh crap, battle time! *adrenaline*" feeling, instead of "hm... loading, I'll get some chips.")

An external setup dialog, so you have at least -some- way to setup the video settings and whatnot without entering the game (I've always hated those catch 22s when you have an unsupported res set in the options, but can't load into the game to change it!)

Menus! (yes, the heart and soul of final fantasy! Coming soon, to a computer near me! This'll be a big step. I'll be allowing both keyboard [classic], and mouse controls for this.. I have some interesting control schemes in mind for this combination that I think will go over quite smoothly, both for the computer gamer, and the classic console diehards.. *crosses fingers*)

Monster! (Yes, singular. It'll probably be a guard. Kinda need something to beat on if I'll get battles to work properly, ne?)

Yah, that's the most immediate roadmap currently. A couple other farther down the line things I'm looking at are Battle scripts, Internal configuration menu, Cinematic modes & cameras, Magitek Armour, and Events(oh, now -THAT'S- a mounthful.. this is the only one that scares me, currently...).

With any luck, I'm hoping to have some more screenshots to show off some of the more visible stuff for you guys sometime in the near future. We'll see how the time:progress ratio works it's way out.

Questions? Comments? Poo-flinging? Offers of first born? All are welcome.. except maybe for the first born. Dern kids. Glad I never was one. ^-^v

Although I don't really understand all of that programming stuff, it sounds like you're making alot of progress. I just have a question though. Is gameplay going to be the exact same? Like, the ability system, in battle, equipment, etc. That's all I wanted to know.

Other than that, keep up the good work!

--------------------

OSonic Rave
/ \Last Arcanum
[ ]Strike Raid
XRagnarok

Yes, the current intend is to have the gameplay the same. Also, current plans include allowing the player to customize a lot of the gameplay. (ie in the options screen, you can enable/disable some of the most common "patches" that have been released for the ROM, that are available on the net, such as the "psycho cyan bug", and "relm sketch" bug.) This is moreso for the purists who wish to play the game in as original a state as possible.

Would it be safe to assume that the Sketch bug will be done away with? Or will that be an option? Or will it be available at all? (I heard it was caused by loading bad sprite data or something. And I guess a 3D game doesn't have sprites...Well, I don't know.)

--------------------

OSonic Rave
/ \Last Arcanum
[ ]Strike Raid
XRagnarok

As I said earlier, the option to have the sketch bug in the game will be available, although by default the sketch bug will be "patched" so that it won't work, as will the "Psycho Cyan Bug".

The actual means thru which the bugs are introduced in the original game will be QUITE different from this one. The intend in this game is merely to have the same effect, not to reproduce what happens internally.

Hey nyxojaele, I've recently become intensely interested in dissecting ff6 myself, and I'm planning on (at least attempting to) build my own version of it from the ground up. I'm not so interested in graphics though -- ideally I'd rather just use the original graphics and essentially build a clone from scratch. Right now I'm figuring out how all of the data is stored in memory, the algorithms used, etc. Have you happened to figure out how the experience-to-gain-a-level data is stored? I see the supposed location of it in the ROM, but I can't figure out how that data is calculated to reach the final values. I've looked through all of the documentation I can find (Lord J's, ZED's, etc etc), but I can't seem to figure this one out. On the other hand, I have Items, characters, spells, etc. all figured out data-wise. I just need to tie them all together and get some actual code going that does something instead of just data structures. I'm writing it in plain C, and actually, at this point, I'm just shooting for a retardedly basic text-based interface just to get the fundamentals going. It's so cool that there are still people actively interested in this -- most of the documentation I've been reading is from years ago.

Well unfortunately, I've never really gotten myself all that involved in the ROM hacking portion of it all myself... Most (if not all) of my information in that regard likely comes from the same places that yours does. I think your question would best be asked in the general direction of some of the prominent figures in the FFVI ROM hacking scene. I believe some may be active on these forums, actually...

On the note of what you're looking for, I have a bit of an interest in that as well. I've found some charts and whatnot of all the values that change, and what they change to, at each level, for each character (if I recall correctly..), but I know for a fact that I have no algorithms for this. I'm -assuming- that FFVI doesn't use lookup tables for these things, hehe ;p

I've actually made some progress on it. Turns out this ( http://masterzed.cavesofnarshe.com/GameDocs/exp.htm ) is not totally correct - some of them are 100 or 200 or 10 off. FF6 does actually use tables for a few of these things, namely:

- how much hp to add when reaching level X
- how much mp to add when reaching level X (hp/mp are actually the only two stats that change when you level up, unless you count esper bonuses)
- how much exp. is needed to get to level X (relative to how much exp required to reach level X-1)

The last part is what I just figured out. The HP/MP gain tables are just 98 bytes each, with one byte for each level (2 through 99) saying how much hp or mp you gain. That's simple. But the experience table is weird. Each element in it is two bytes long. (byte0 << 3) + (byte1 << 11) gives you the amount of experience needed, again, relative to the previous level. The relative part is what I didn't realize until just a little bit ago. So I guess I'm good to go.

This post has been edited by mackstann on 14th March 2006 14:36

Thanks for the clarification on the tables bit. I really wasn't sure. As I'd like to have my game as accurate as possible, I'd muchly appreciate any updated tables you'd be willing to release to the general public.

Something that just crossed my mind: Perhaps you should ask MasterZed about the article in question. Maybe there's some specific reason that his numbers differ from yours.

That's an interesting find of yours tho-- I've always been interested in ROM hacking, but I just haven't had the -time- to devote to it, unfortunately;; Tho, I do enjoy reading up on the things people find, and how it all fits together.. at least, in regards to FFVI. ^^v