River Nyxx

Unfortunate setbacks~ >_<;

2009-08-03T21:50:00.001-07:00

So I've been spending a large portion of my absense from the blog, working on various editors associated with FFVI3D, (I can't go into detail yet until they're more fleshed out- but they're intended as development tools that wouldn't see the light of day even on a professional game) as well as some side-projects of mine that I'm also intending to add into my cyberportfolio.

This weekend my house experienced a power surge, and it would appear as if my surge protector didn't very well succeed in doing it's job, as I am now finding myself with a couple of video cards that no longer perform all of their required duties properly. At least, that's how it's looking for now. Needless to say, it's quite difficult, nigh impossible to partake in certain hobbies of mine, and as such, it appears that FFVI3D's programming will have to sit at the wayside until such a time that I can get my computer properly repaired. I fear that such a time may be farther away than I would really like >_<;

Quite the undertaking...

2008-12-13T14:07:00.000-08:00

So the new File Manager I'm working on it taking quite the amount of time to properly implement, as it requires re-writing of EVERYTHING that loads from the HDD into the game- and it all has to be done in my special new format to allow easy saving to the HDD, as well as unloading of files, if it's supported by that particular filetype.

Everything is being done in a modular style, so next time I want to add a new type of resource for the game to use, I just have to create a new module to plug into my as-of-yet-unfinished File Manager.

Once I'm done with this (who knows?) I think I'll go back to working on that modular attack system I just barely started a month or 2 ago. I think that's going to turn out well- and what's got me really excited about it is that it's going to be generic enough that I can use it on virtually any game I write from now on~ It'll support everything from "basic attacks" such as attacking and healing, up to "complex attacks" such as changing gravity, hurling objects via physics, setting game flags, or any other imaginable attack effect.

With the systems I'm creating now, I'm already thinking about my future projects, and trying to make things generic enough that they can (mostly) be used from project to project. This'll save me boatloads of time on future projects, as well as allowing me to improve on my already tried-and-true systems that I have in place from my other games.

< /Summer >

2008-10-17T22:39:00.000-07:00

Okay, so now with Summer out of the way, I'm starting to have more time to program again-- the summer festivities always tend to take away from that. I still have to survive thru Halloween, as the costume/party preparations are still taking up a bunch of my time, but that's just like summer- it happens every year.

I worked my way thru a bunch of memory leaks (one of which had me pulling the entire engine apart to find it!) and other boring stuff that won't really interest anybody, but while doing so, I've had more time to reflect on the class structures I've got in the current iteration of the battle state. I'd have to say that as things stand right now, I'm really not happy with how it all works together- it's just too messy, and horrible to read/maintain.

So I've decided I'm going to rewrite the classes for handling actions in battle, and am seriously considering rewriting large portions of my script class to add more versatility to it. I've learned from reverse engineering another game in a side project of mine, of some other methods to load scripts into RAM that will provide easier access to various things such as variables, etc..

Battle actions will be rewritten in such a manner so as to be more generic, and modular. This'll not only provide me with reusable code, but also an easier means thru which I can add more actions to any "battle" in whatever game it is that I'm programming. This class is going to be quite powerful in that it can accept actions that do virtually anything in the game, but all thru a generic interface that makes the custom actions rather easy to write and plug-in, quite possibly by means of my script class as well, but we'll burn that bridge when we come to it.

All that said about the future, what have I actually done lately? Sadly, not much- but I -have- already started taking steps towards the rewriting of the battle actions handler, in that I've written some base classes and gotten it basically "working", although not really tied into the engine properly yet. That'll all come with time.

while (!sleep) sheep++;

2008-05-26T21:16:00.001-07:00

So I've been spending the last few weeks implementing battles and the associated algorithms into the game, as well as occasionally being unmotivated, and instead playing video games. Regardless of which activity it is that I'm involved in for the night tho, I haven't been getting huge amounts of sleep, haha ^-^v I've started trying to go to bed earlier tho, as I've found my cognoscence start to lack when my sleep levels get too low, which ultimately results in less production by time.

I've gotten so far as to implement a rudimentary battle interface with the basic commands "Fight" "Magic" and "Item"- although currently "Magic" and "Item" do nothing. I've also put together a fairly extensive set of algorithms for hit detection and damage calculation. Virtually every type of attack can now be made with these 4 functions. I've put these 4 functions into their own class that can be configured remotely by scripts. Typically, each script will do the same thing, that is, ask the player to select a target, pass that target to the attackHandler class, pass the type of attack being made to the attackHandler class, and request the attack be made. The only different thing a script may want to do (off the top of my head) would be to request an attempt at applying a status effect on the target. Everything else tho, instant death, elemental weakness, etc.. is handled in the attackHandler class.

That in mind, it will be virtually nothing to actually start implementing spells and have them called with the "Magic" option in the interface. I'll just have to put something together to allow the player to select a spell (or an item, in the case of selecting "Item"). That's really the only reason those 2 options aren't functioning yet.

I have a basic "target selection" system in place, but for all intents and purposes, it's just for me to throw a target at the attackHandler class. It's going to get almost completely rewritten for end-product.

Additionally, I've started implementing custom sceneNodes and sceneNodeAnimators for my specific needs in the game- things like the movement/fading/etc effects of the damage text and whatnot, that appears briefly on the entity in question.A couple of bugs have been preventing me from expanding too much on that yet, but the basic effect is there.

I had to start teaching myself some DirectX (Irrlicht typically hides this from the programmer...) so I could write some custom material handlers for Irrlicht, as it didn't have a material or 2 to do some of the things that I want.

Polishing and upping the standard

2008-04-06T22:51:00.000-07:00

I've now gone back and polished up the GUI Manager, and the Script Manager to support more things-- most notably, the GUI Manager now supports scripts being executing on various other events other than merely selecting an item.

Scripts can now be executed when a layout is shown/hidden/paused/resumed, and also as a cursor moves in any of the 4 cardinal directions off of any given item.

Additionally, the layout files can now pass a single identifier into the script they're calling, so a script can be aware of which GUI element is calling it. This will allow the scripter to use a single script for multiple GUI elements. More relative values can also be used for placement/sizing options for the various GUI elements, such as percentages, and centering. This will allow for GUI windows/etc to resize themselves based on the resolution of the game.

On top of those feature additions, various small bugs have been squashed, and some optimisations implemented as well. I'm shooting for a professional level game here, so I want the code to be as robust and efficient as possible.

As far as my work on the battle state goes, I've created the basic classes required for character creation (and theoretically, monster creation as well, although it's not currently implemented...) and have created all the necessary data files for all of the 14 standard characters that will be playable during the game. All of their data (even the unimportant stuff, such as background info) is loading correctly, and I've also created everything required for levelling up, so I can now create any of the 14 characters at any level, and all the numbers will match the original game.

I have yet to decide exactly how I will format temporary playable characters such as General Leo, Biggs, Wedge, and Banon tho.. If I take a hint from the original Super Nintendo game, I'll end up creating them exactly like the other characters, and just never introduce a situation that will allow them to remain in the party permanently. That's still some time away tho, as I still need to implement more important things such as monsters, and the actual battle sequence!

Graphically, I've put together a basic system to allow character meshes to be composed of 3 pieces: Legs, Torso, and Head, (ala Quake3) which will allow for much more complicated animations with much less work required.

Some of the next things I'll be working on will be the scenery loader, to properly load the battle scenery/information, monsters, and the monster formations. Once I have that all in place, then technically all the data I need will be loaded, and it will just a matter of manipulating it to actually perform a battle.

Time to get this battle started~

2008-03-19T19:21:00.001-07:00

Okay, so I've now gone thru and finished off my script manager, and I've created a screen processor for handling full screen shaders, "filters" if you will. I can now stack filters to have multiple effects at the same time, applied to either the 3d Scene, or the whole screen including the GUI. I've written up a simple "mosaic" shader in HLSL and it now gets applied to the screen (with varying strength) when you try to select a disabled menu item, or back out of a menu you're not allowed to back out of.

I've also created an audio manager for handling of all music/sound effects in game. Currently all it does is act as a music play control, and a means thru which my classes can acquire 2d sounds, that is, sounds that don't represent anything in 3-Dimensional space, such as GUI sound effects, etc... Once I start having something in a format I want to represent it in, in 3D, I'll be throwing in the functions for 3d audio as well. And that, my friends, should be coming soon enough.

I've got back and streamlined a bunch of my initialization functions, making them faster, and more importantly, I've implemented a means for the game to compile my custom scripts into a format that it can load MUCH faster. I ran a test on my long test script, and when left to parse/load the raw script, it took 183 milliseconds to load, but after compiling it, just loading the compiled version took under 2 milliseconds! Yesyes, much better. *nodnod* FFVI3D can also load both compiled and non-compiled HLSL shaders now as well.

The commands available to the scripting language have been extended a touch to include option value acquisition as well. And also scripts can now be attached to interface layouts, to be executed when the layout is opened/closed/paused/resumed as well, which is quite useful for self-adjusting layouts, such as an options/config screen.

So now, I'm looking at what to do next, and I think it's finally time to start dipping my toes into the battle-state lake that I have been eyeing for quite some time now. Tonite I'm going to start work on some of the frameworks required by the battle-state so that I can start coming up with something real to show off sometime in the hopefully-not-quite-so-horribly-distant future^^

Script Manager down, who's next?

2008-03-01T21:03:00.001-08:00

So, the 2nd iteration of my Script Manager is up and running now. Everything is working beautifully, it's fully recursive, which means I can have expressions with parentheses, and math in function parameters, etc.. It also looks a LOT like C++... the only really noticable difference is that I don't use curly braces ( "{" and "}" ) anywhere, and opted to instead go for a "if/endif" and "while/endwhile" route instead. Other than that, it looks quite a lot like C++, function definitions, etc.. Well, I guess more appropriately, it would be closer to C, since my scripting language doesn't support objects, but whatever.

So this is the final test script I was running to make sure everything was working fine (and it is!), just so you can have a taste of what the language is capable of. Take note, that this doesn't actually make any calls to functions in the game itself, but they are fully supported (I was testing those in a different script file...)

number testFunction5(number x, number y);
number i;
i = 2 * (2 * ((1 + 1)) + 2) / 3;
print("*****FINAL RESULT*****");
print(i);
number r;
r = 5 * x * y;
r = r + 50;
r = r - 23;
r = r / 10;
string tst = "part1:";
tst = tst + "part2";
print(tst);
return(r);

void testFunction2(number num);
print(num);
num = 45;
print(num);
return;

string testFunction(string str1, number numbah);
print("Output- displays nothing since it is only useful mid-operation");
output;
number num = numbah;
print(str1);
print(32);
print(num);
print("constant text called explicitly");
expose;
return("text returned from function to main");

void testFunction3();
print("Test function 3");
return;

number testFunction4();
return(1337);

entry;
number n1;
boolean boo = false;
string s;
print("Before loop scopes:");
expose;
print("Inside loop scopes:");
while (n1 == -1 && !boo);
print(s);
s = s + "a";
if (s == "_aaa");
boo = true;
endif;
expose;
endwhile;
print("After loop scopes:");
expose;
while (n1 < 20);
print(n1);
n1 = n1 + 1;
endwhile;
while (n1 <= 40);
print(n1);
n1 = n1 + 1;
if (n1 >= 34);
break;
endif;
endwhile;
string str1 = "yay!";
string str2;
number num1;
print("Before ifelse scopes:");
expose;
if (str1 == "yay!" && str2 != "" || num1 == 0);
print("Inside ifelse scopes:");
expose;
print("Before if scopes:");
expose;
if (str2 == "_");
print("Inside if scopes:");
expose;
print("true");
endif;
print("After if scopes:");
expose;
else;
print("false");
endif;
print("After ifelse scopes:");
expose;
number num2 = 100;
str2 = "text";
num1 = 50;
string str = testFunction("text passed to function and thus is stored in variable", 42);
testFunction2(3);
testFunction3();
number ret = testFunction4();
print(ret);
print(str);
number n = testFunction5(num1, 23);
print(n);
boolean b = true;
number nr = 1.5;
print(nr);
expose;
end;

Of course, all of the variable names, constant values, etc.. are all random and make no sense whatsoever, as they were only being put in to test specific constructs in the scripting language itself. As far as the scripting language itself goes, there's only 3 things I'm currently considering still putting into it: do/while loops (which we can do without, as we have a basic while loop...), and for loops (which we can also do without, but it would be less scripting for a simple type of loop, if it was implemented), and lastly, a means to have the script wait for something in-game to occur, and trigger the script back into action again to finish off. The main thing I'll need this for is to implement in-game cutscenes, so I can have a script (for example...) tell a character to walk north 10 meters, at which point the script will wait until the character arrives at that point, at which time the script could continue to tell that character to say something, or some such.

Now I'm quite firmly involved in finishing off all the little notes I left for myself in my code months ago. With all those little things done, I'll be working on the battle state.

Script Manager is live!

2008-02-12T21:14:00.000-08:00

I've now got a working (albeit just barely) script manager implemented into FFVI3D. It's composed of a virtual machine that interprets opcodes that are all linked in sequence in a script object, for the most part. It also acts as (currently) a dumb interface to simply execute a script by name (as saved in the script file).

The scripts are saved in a pseudo-XML format, in that some script parameters are stored in XML, but the main part of the file, the script, is stored as plaintext inside an tag. The scripting language I've created for FFVI3D is currently pretty limited, as I still have yet to implement a lot of the major things in it. But the opcodes are there and accepted fully by the virtual machine, it's just that the parser doesn't yet convert script into opcodes for everything yet.

A simple exaple of a script that I have currently, which I was using for testing is this:

function test(string:text);
print:text;
print:"const text";
return:"arg";

entry;
test("var text");
print:"return text";
end;

So as you can see, it currently supports defining in-script functions, and some simple print-to-console commands. It also supports other commands such as one to show a gui layout by name, one to hide the current gui layout, etc.. but they aren't in that test script.

I'll be spending the next couple of days implementing the remainder of the major parser script-to-opcode conversions, and an automated means thru which an object in my code can contribute any number of it's own functions to the list of available functions, as well as automated means for the parser to know/use them.

With that outta the way, I'll be going back to my to-do list, knocking off the remainder of the small stuff that I had to touch up in my reworking of the code. This scripting thing was by far the largest thing on that list, so the rest of it should go pretty quickly.

On the horizon: I'm going to start seriously looking at managers required to start a battle game state. In the coming weeks/months, I think we can look forward to a battle state slowly starting to show it's ugly head in the works, which will be the first _REAL_ visual experience of FFVI3D- I'm all excited about that^^

A setback, and starting with new things...

2008-02-04T17:22:00.000-08:00

So I spent most of last week working out some way to effectively change the resolution of FFVI without having to quit and restart. You see the issue is that with the Irrlicht Engine, you cannot dynamically change the resolution and everything will be fine. You have to actually properly shut down the IrrlichtDevice and create a new one with a different resolution setting.

I spent about 3 or 4 days working some code in to make sure everything that needed to know the device was going to change, knew.. but it started getting to the point where I was writing a hack to make a hack work so it would hack another hack into making the whole thing work. Not even close to clean. I can deal with some hacks, as they tend to be temporary, but this was just getting rediculous, and I knew some of them just couldn't possibly be temporary.

So I scrapped everything I had done in that direction and looked at it from a different perspective after taking a small break. In a matter of 2 nights, I wrote up a new means thru which to not only effectively, but CLEANLY do what I wanted to, and I proceeded to work out all the memory leaks, and all now looks well^^ I'm quite happy with how my code turned out.

After that, I went thru my to-do list, cleaning up a buncha stuff that got dirty while I was doing all this, and got back down to the major points on the list again. The 2 things that really stuck out was to go back thru my code and fix everything that I had left notes to myself to fix, and to implement a means thru which the various menu items could actually DO something. (Technically, the latter is a member of the former, but ah well...) This menu item action thing is actually the last piece I need to implement to have 100% of my previous code working again, but it's actually going to take a bit before I get them working again, as I'm going to do it properly this time.

And the new thing! I am now writing a virtual machine to execute external scripts. These scripts will be specific to FFVI3D, but will be easy enough to figure out. They'll likely be in a similar style to BASIC, but I might go so far as to make them feel more like C/++.. Not that any of this will matter to the player, but it'll be a LOT easier for when I get around to putting some events/ingame cutscenes/etc.. in. I'll also be using scripts to define what each menu item will do when selected. But I really haven't gotten far into this yet, so I'll update later on it.

Beginnings of real profiling, and small additions

2008-01-29T21:35:00.000-08:00

So I've almost completed all of the little bits and pieces of my rewriting of my old code, and I've actually added some considerable amounts of other new stuff also while I've been going.

One recent addition was an optionSurveyor abstract class, so now I can have any class derive from it, and register themselves with the optionManager to receive news of changes in specific options. Very useful-- this'll allow me to make sure that as soon as any option is changed, all of the appropriate places will be informed so they can act accordingly- and if they're not, it'll be easy to make it so they are.

In doing that, I've started adding more support for actually CHANGING options dynamically while the game is running, such as resolution and whatnot. Virtually all of my currently used options can be changed runtime now and everything will restructure itself to accomodate the new options, but in setting up things to work with a resolution change (by far the most complicated option to change, since I need to completely remove the engine device and recreate it, losing a good portion of my dynamic data in the process...) I've noticed that I've got something that I'm questioning as whether it's a memory leak or not. "Memory fluctuations," I'll call it.

So I've now dug out a highly recommended profiling tool called AQTime 5 that so far I am [b]very[/b] impressed by. And it's promising much more than I could possibly ask for. With a price tag of only 5 or 6 hundred dollars, I'll have to give some serious consideration to purchasing it. Or a PS3. *shrug* But for now, I'm enjoying all 2 days of the demo that I've experienced so far.

I've been using it fairly extensively (after reading the boatloads of documentation required just to get STARTED with it!) to find many leaks in my code that I didn't even have a clue existed. I hadn't noticed them because they weren't continuous leaks, but rather gradual. A small leak in an initialisation routine here, one over there, etc... As opposed to something that's puking out 3mb of ram every 2 seconds, which I'm happy to say, I've caught all of so far.

With the help of this profiler, and having to patch up various small leaks, it's also forced me to structure some of my code in a better way to allow for some future code that I'm planning on as well, which is good. I think AQTime 5 and I could become pretty good friends. *sagenod*

Since I'm not even going to look back at all at my old GUI code, I can't get any hard numbers for you, but I know for a fact that now that it's about 98% recoded, I'm quite confident that it'll run significantly faster, cleaner, and more readably (I know, the last one only affects me..) than ever before.

I've also gone so far as to download the DirectX SDK and recompiled Irrlicht with symbols to help with my debugging, as well as allowing me to compile it without certain features that I never intend to use, allowing it to be significantly smaller, which is good. I won't know for sure how much smaller I can get it until I've virtually finished the game engine, but I suspect pretty small, as there's a lot of stuff in there that I don't necessarily need ^^v

GUI Rewrite

2008-01-21T15:13:00.000-08:00

So I've all but completed my re-write of the GUI system in FFVI3D. I completely reworked how drawing was being handled by the different gui elements, and made the gui skin class act more like it should. Now the gui skin class actually has drawing functions for the fundamental ("primitive" if you will...) drawing aspects of the gui elements, and each element calls the ones it needs.

Additionally, the rectangles for the gui elements used to get recalculated every frame, but since the gui elements in FFVI3D will never change shape dynamically, there's no reason to do that, so I have them calculate them once when they're created. If at some point, I decide to allow them to be changing shape/position dynamically, it won't be hard to implement functions that will recalculate the rectangles at only that time, instead of EVERY frame, which is just wasting CPU cycles.

I completely re-wrote the XML loading algorithm to be not only more effecient, but to work in a cleaner, more appropriate manner, there were some gui elements that I used to stuff with some read-in values, and "init'd" them later, once all of the other elements were loaded (such as the direction map for selecting another gui element via keyboard/mouse wheel), but now I've come up with a way to allow me to link them together linearly so there's no need to "pre-init & init" them anymore. Cleans up the code a lot, and I'm a LOT happier with how it fits together now.

I've also gone thru and replaced all of the gui elements' texture references to instead be pointing at my custom animated texture class instead, meaning that EVERYTHING on the gui can now be animated, including the mouse cursor. For comparison, the only thing that used to be animated was an "overlay" object, which could be anything really, but at the point I had gotten to, that only applied to a flashing "selection bubble" overlaying the currently selected menu item.

Speaking of which, I reworked the animated texture class, so that when you're requesting the current texture, it no longer iterates thru a loop of mathematical calculations, but instead does some simple division/modulo calculations on 1 or 2 lines, once only. Also, no calculations are done at ALL if the animated texture doesn't contain any frames, or only contains 1 frame. Lots of fun little optimizations like that, I've been putting in as I go thru all of my code and rework it. I can really see this already running a lot better on the PSP than it did.

I also started implementing reference counting on my non-Irrlicht classes, using the Irrlicht reference counter class. Nothing major, but it makes for code that's easier to maintain.

Look forward to the last of the GUI reworking, and then various other small things that I haven't gotten around to re-enabling yet... After that, I really don't see much left for the rewriting- so I'll be looking forward to working on new features soon!

Re-arranging and getting caught up

2008-01-08T15:01:00.000-08:00

So I've almost completed my reworking of the FFVI3D game engine up until the point I had it before I went on my break. I've just gotten to the point of working on the GUI, which means that almost ALL of the rest of the framework is already in place-- and then it's just a matter of trudging thru all the different GUI elements' code to make each one work.

I've been moving various functions around to their various PROPER places, to tidy up my existing classes, as well as to more accurately have each class doing what it's supposed to do. I used to have a series of classes I called "managers", but have come to the conclusion that they're actually more like 2 different series of classes- one of which is still the "managers", but the other is more like... "sub-managers" or some such. So I'm pulling out the whips and chains to put them down where they belong- back in the dark recesses where you won't see them, but rather their results.

I'm going to be completely reworking how the GUI layouts are stored in memory as well, to not only save memory, but also to allow (theoretically) for more layouts to be loaded at the same time. I had been thinking about doing this while I was coding it, but I just kept putting it off, and now is the perfect time to do so, since I'm reworking everything anyways.

Once I've caught up with reworking my code again, I'm going to make this a lot more serious and technical, as I discuss in more detail about what I'm doing, but in the meantime, it's just general updates on what's happening. Also at that point, I'll be using Labels for the posts to make it easier to find specific updates.

Reworking the old...

2007-12-29T12:25:00.000-08:00

So the past few weeks, aside from celebrating the holidays, has been spent going thru all my old code and reworking it. I've learned a lot of things during my "time off" and I want to apply them to the FFVI project, so I've been going thru and basically "rewriting" my code from scratch-- that is copying individual classes, function by function, from the base and working out, applying everything I've learned up until now to my old code to bring it more up to date.

Other than the reworking of my code, there's been minor tweaks and changes made during the porting of the code back to the PC, but it's all very much the same-- some changes in input since we're not dealing with buttons and analog sticks, but a keyboard and mouse, etc..

Nothing really to go in depth on yet until I've gotten everything back up to speed- but so far I'm happy with the improvements I've been making to my code, it'll speed things up nicely, which I was starting to get a little concerned about with how it was running last on the PSP.

Back in action!

2007-12-11T05:41:00.000-08:00

So, it looks like it's time for me to start getting back into this project here. I know it's been a long time, and I apologize for that- I just needed to get this other thing out of my system. I no longer have the motivation to continue that other project (nor did I really -intend- to finish it), so I feel I can return to FFVI3DPSP without the desire to look elsewhere.

As an update, I've made a design decision to continue using the Irrlicht Engine for the game, but to do the development entirely on the PC instead of the PSP for the time being. The main reason being that it's much easier on me to program directly for the PC during the main part of the development process, and then just "put it on the PSP" later, and only do my debugging for the PSP portion of it ON the PSP.

This can now be done because the LTE Game Engine has now become open source, so in theory, I should be able to port over whatever version of Irrlicht I decide to use, into the LTE Game Engine source, to allow me to use it on the PSP as well, of course, taking into consideration that I'll need to avoid any features of the Irrlicht Engine that aren't supported on the PSP.

So, development will continue on the PC for the time being, with the eventual intention to port back to the PSP. No promises on that porting, 'mind you, but I'm still going to develop with that intention, avoiding things that can't be done on the PSP, etc..

Wow- I did a search just now about my project. I never realized how much word has gotten out about it...

I've also decided that I'm going to start accepting outside help in a limited capacity- since I seriously want to finish this, I'm going to focus my own efforts entirely on the programming aspect- which'll mean that I'll need some outside
help for other things.

I'll be editing this (and the top) post with additional information about helping out in the future. Take note that this isn't intended to be a next-gen game, so I don't need ultra-high end stuff here. (although it's appreciated, and can definately be used!)

Basic NDA/Disclaimer that must be agreed to if you want to help (a more detailed one will be available on request, after I've put it together...)

Recognize that this project is still intended to NOT be publicly released unless we receive explicit permission from Square-Enix themselves. I reserve the right to be in control of communications in this aspect- with feedback from other group members.
No outside advertising for this project that hasn't passed by the Nyxojaele filter. I still maintain this as my own personal project, so I don't want somebody else going on about it behind my back.
Works for this project shall be entirely original and created specifically for this project. You still retain your rights to the works, but are not permitted to use them for "other projects" (personal portfolios etc are fine). Additionally, full credit will be given for all works. Please note that it is not acceptable for ANY works to be downloaded from elsewhere- they must all be original works to which you hold the rights.

Positions where help is specifically desired right now:

Concept art- Skilled art that maintains the same "feel" as the original game held is desired. Taking influence from (although not duplicating) Amano-sama's art is perfectly fine. Attention to detail is a must.
Sound effects- High resolution recording of sound effects is desired- we can downsample later, but can never upsample for an increase in quality. Creativity is a must- how else can one create sound effects? Proficiency with an audio alteration program a plus.
3D models- Skill in both high poly-count & low poly-count in-game models. Cinematic poly-count model skills a plus, but nowhere near necessary. Cinematics will only be added to the game if a sufficient skillset can be acquired for the team.
3D levels- Architectural eye a must. Ability to create full 3d models of the original locations found in game- attention to detail a plus, but since this may be on PSP, we might have to budget our poly-counts.
Texture artist- Skill with high quality, low/medium resolution textures- we don't want to be using up boatloads of memory for just textures.
GUI artist- Good looking yet simple GUI element graphics are needed- probably on a "skin" basis. That is, there will be more than one GUI "skin" available for the player to select, as is Final Fantasy tradition.

These are just the currently desired positions for the project- if there's something else you think you can offer that will benefit FFVI3D, then please post here and let me know and I'll see if it's a viable option.

Back from Japan!

2007-12-11T05:40:00.002-08:00

Yes, it has been a while since my last update/post to you guys. And I have to say, unfortunately, that there is nothing to report. As I last said, I headed out to Japan- and I was there for 2 months. Obviously, during that time, I didn't want to be working on any of my projects, so nothing happened during that time.

Upon arrival back in Canada-land, my workplace decided that since sometime late last year, I'd gone on a trip for the company, I was a prime candidate to make continued trips all over the place for various reasons vaguely along the same lines as the first trip held. That in mind, I've been travelling all over the place, and with all the stress entailed with that, I've not been up to the task of working on any of my huge projects during that time, not to mention that a good portion of my free time is eaten up with all the travelling, plus the fact that I work a minimum of 10hr days while I'm away from home. Stress++ ( -_-)zzzZZZZ

During this summer, I spent a grand total of almost 2 weeks at home. The trips-for-work thing should be calming down sometime this fall tho (I hope!), and I want to assure you all that the project is NOT dead, despite what many of you would say. I still have it, and I still want to work on it. Just my life is currently not allowing me to. In it's stead, I'm working on smaller projects that don't require such a huge portion of my life, until my life (mainly my work situation) straightens itself out enough that it'll allow me to get back onto the FFVI3DPSP project.

Yes, I'm aware that it sounds like I'm making excuses, and yes I'm aware that many people are interested in seeing progress with the project despite what my personal life might be like, so I must apologize to you all for that. All I can really offer to you in that light is the knowledge that the project will be continued as soon as circumstances allow.

On the bright side, some of these smaller projects I've been working on have given me new insight into many programming aspects that I can apply directly to FFVI3DPSP, so I'm really looking forward to [re]writing the appropriate portions of code and see how well it works!

To anybody interested in these small projects, the only one worth mentioning is called PACNyx. It's a utility for [eventually] creating mods for a game called Ragnarok Battle Offline (a doujin game based on Ragnarok Online). I'd provide a link, but I'm too lazy to check the forum rules about posting links to other forums, so if you want to read more about it, PM me.

I hate bugs><

2007-12-11T05:40:00.001-08:00

~whew~ Yah, it's been a while since I've updated you guys on what's going on. Unfortunately, I don't have much to report. I've had this ONE STINKING BUG holding me back for the past 2 or 3 weeks (because I'm stubborn that way, and not to mention other things going on in my life) whilst I tried to find out where it was. It was getting to the point where I wasn't looking forward to coding after work anymore.... BUT~! I've finally gotten the derned thing (literally, about 5 minutes ago), and progress shall now continue as advertised... sorta.

Programming will continue, but I've got to put a lot of my free time now into preparations for my coming trip to Japan. March 19th I fly out, and I'll be there on holidays for 2 months! (read: w00t!) I'll be bringing my laptop with me so if I find myself up late at night with naught a thing to do, perhaps I'll bring myself to code some more of the game, but it will BY FAR be at the wayside for while I'm out there. Upon return tho, after the required recovery time, it'll continue at the usual pace tho.

Just to give you guys an idea of what to expect in the foreseeable future.

Octrees and terrain... and tutorials.

2007-12-11T05:38:00.000-08:00

A small update on what's been going on. My most recent portion of code has been involving the terrain, and how I'm going to be structuring it in the PSP's RAM. My decision was to use an OctTree to display it.

OctTrees 101: We decide on a constant value. This value is how many triangles of a 3d mesh we want as a maximum inside 1 OctTree node.

Now, imagine putting a 3d mesh inside an invisible box. This box is your "root" OctTree Node. Now divide that box in half, 3 times. Once on the X axis, once on the Y axis, and once on the Z axis. This will result in 8 equally sized "child" nodes of the "root" node.

Check each child for the same thing, does it have more than our constant value we decided on earlier? If so, divide that child into 8 smaller boxes and continue doing the same checks/divides until every child has less than or equal to our constant value, triangles inside that box.

The benefit of this is that I can tell the PSP to only draw the triangles inside the OctTree nodes that are visible right now. This saves the PSP all sorts of computing time.

So, OctTree it is. Unfortunately, I'd have to calculate that octTree everytime we load the world map (which would likely be only once or twice per gaming session), and on my example map (which was QUITE small), that was roughly 8 or 9 seconds of waiting. In my opinion, that is unacceptable.

So, as of late yesterday afternoon, I finished writing my "OctTree Serializer" which basically takes that whole tree of OctTree nodes (starting with the "root" node, and all 8 of it's children), and saves all that calculated data (which triangles are attached to which of the imaginary boxes...) to a file. So now instead of loading a 3d mesh and calculating an octTree for 8 or 9 seconds, I will load a 3d mesh, and load an ALREADY CALCULATED octTree and attach them together. I haven't finished integrating it into my game yet, but stand-alone, it is fully functional, and I suspect the loading time will be cut down to likely less than a second.

Something kinda humorous. Typically, programmers will write small programs that will do something for them, to make their programming lives easier, or maybe write simple editors & whatnot to make creating content for the game easier, etc... Normally, regardless of what platform the game will be for, since it's being programmed on the computer, these "supporting programs" will usually be for the computer, since they'll never get distributed with the final product. Well, this is my first "supporting program" I've written for FFVI3DPSP, and what's kinda funny is that I made this program specifically to work ON the PSP, to help me create the content I need for my game on the PSP.

During the time that I was working on that program, it had come to my attention that there was some demand for some tutorials on programming for the game engine I'm using, the LTE Game Engine. So, since I felt I needed a small break, I promised them I would write a tutorial or 2 after I finished my supporting program. So yesterday evening/night, I wrote 2 tutorials on LTE GE Programming. For anybody who's interested. These are posted directly on the LTE GE forums, since that's what it applies to. I hope it's no problem to post these links here.

Creating a "barebones" application in the LTE Game Engine
A Gamestate Handler in the LTE Game Engine

Since I've now got that tutorial writing thing outta my system, I'm going right back to programming, and I'll be integrating an "OctTree Deserializer" (it loads the OctTree from the file, instead of calculating it) into my game now. Maybe, if there's enough interest, I'll be writing some more tutorials at some point, since I can do them relatively quick. But by far my main focus is still my game programming.

With this simple terrain stuff I've been writing, I'm starting to see the limitations of the PSP's CPU. I'm gonna have to start being creative with how many triangles are being rendered at any given time in order to keep the framerate at a respectable level. With RPGs, I believe that a lower framerate is acceptable than for FPSs and such. I'll probably be shooting for a bare minimum of 20-25 frames per second, although ideally I'll want 60, which is the PSP's builtin maximum.

3D Mesh thoughts

2007-12-11T05:37:00.001-08:00

Small update on the way things are going right now: I've been sick for almost a full week now, so that's both a plus and a minus; if I miss work, I can program more, but since I'm sick, I haven't the energy to program as much. ;

Regardless, that wasn't the update I'd intended for. I've been doing some research into which 3d format to use for the game, and I consider it likely to be a combination of .OBJ files for static (non-animated) objects, and .B3D files for animated objects. B3D supports skeletal animation, at only a slight cost to the CPU over "baked" animations, so I'd very much like to use it if at all possible. Even if I can't do skeletal animation for whatever reason, B3D still supports "baked" animations as well, so life is grand, and the people rejoice (yay...)

Anyways, I've gotten myself another copy of Blender (a freely available open source 3D program that rivals many commercial programs out there...), and I'll be putting together some simple models for my own debugging use. I'll probably have every single debugging model I'll ever need done in less than a day. They're all so simple. The only limiting factor on me right now is the blender exporter to B3D format, which is currently "in testing", or so I've been told. I've gotten in contact with the exporter's author about it's status, and I'm just waiting on that. SO, until I have that exporter (or am informed that I will never have it, so I can start using a different taskflow...), I'm putting animated 3d models on hold for the world map state. 90% of my debug models will likely be unanimated anyways, so it's okay. With this bit of news tho, I'll be concentrating for the time being on some of the other things I've kinda put to the side, but as you can clearly see I am working on the world map state now! I've actually already created some GUI layouts for use in the world map state, such as dialog boxes and generic text output to the player.

Gameplay stats and roadmap

2007-12-11T05:31:00.000-08:00

So, a small update on the actual game now: (Yay- something worth typing/reading!) I've spent the last week or 2 cleaning up my code, and putting a lot of error checking in. Most of the error checking, and it's associated output messages will not make it into a "release build" (for non-programmers, that's a version of the program that runs the fastest, with debug features disabled..), but they are SO incredibly useful for me during development, I'm surprised at how far I've gotten without them so far! Not to mention, that I was starting to get concerned with certain parts of my code becoming messy, and now, I'm actually quite happy with the state of my code. During this time, I've also moved a lot of the code around to where it belongs, etc...

Before I continue too far into coding new stuff, I'm going to take the time to document my code better so it's easier for me to quickly identify everything about my functions, down to the little details, so I can stop siphoning thru code to figure out some little thing about a specific function.

I've also recently written a video manager to wrap around the video driver provided by the LTE game engine. Yes, I'm still working on core objects for the game.

For anybody interested, here's some random statistics about the game:

Source code: 174kb in 35 files
Executable: 2,042kb (about 1900kb of this is just the core LTE game engine)
Content: 1.75mb in 25 files

Framerate during intro sequence:
With logo visible: 30 (logo covers most of the screen, and has heavy transparency)
Without logo: 60 (looks like it's capped here...)

If all goes well in the coming week or 2, I should have everything done with my current state (and bugs), and will be moving on to working on the world map. And additionally, a specialized form of the world map designed for in-game cinematic sequences. (This being merited by the Armortek trek across the snowfields into Narche at the beginning)

I've spent a tremendous amount of time optimizing code and wrapping my own stuff around LTE GE's functions. The result: A massive increase in speed/stability, not to mention slightly less memory usage.

My FPS stats from before are now officially ... not official. no more. During the beginning of the intro sequence (with the clouds...) the FPS is 30, and goes up as the clouds move off the top of the screen. I've still intentions to look into this, as it may manifest itself later in the game, so I should take care of it now. I wonder if it's something to do with displaying an image covering the whole screen, using alpha transparency?... kinda doubt it because the logo that fades in later uses even heavier transparency, and covers about 3/4 or more of the screen as well. I'll see about it later. Anyways, after the clouds have scrolled off the top of the screen, I get a constant 59/60 FPS (I typically get 59 even when it's actually 60. Likely a rounding issue..), even when my GUI is displaying, which is to blame for a good portion of my coding time recently. The FPS drops a bit (maybe to mid 40s) if I open up my debug test GUI window which uses a LOT of different GUI Elements at the same time, most of which are using transparency. I'll likely change this so it gives improvements in performance, but for now, it's fine.

I've also hit a bit of a milestone in the programming for this thing, and it's also a random stat I forgot to give you last post. This should give you some kinda idea about how much goes into this stuff (read: CRAZY!) The total lines of code I've written so far for the PSP version of my game is: 10,040. Holy crap. I can now officially say that this is the biggest programming project I've ever done. I've never broken the 10,000 lines barrier in a single project before. *champagne*

Of those 10,040 lines, 4,508 of them are JUST GUI stuff. Heh- almost half of my work so far is just in the GUI. But in a game that is based so heavily on the GUI, I feel that this is justified. ^-^v

So, stuff I've done recently:

The GUI is now completely customizable: To create a new GUI skin, all I have to do is create a new directory with the GUI skin's name, and fill it with the appropriate graphic/xml files defining that skin. The game will detect the new directory and give it as an option when the player is selecting their GUI look.

Animated 2D Textures: The LTE GE originally supports animated textures on 3D objects, but nothing for 2D (ie. GUI), so I've put in support for that. Meaning that now I have support for some very pretty looking effects on the GUI, besides just the moving cursor.

FPS based 2D movement: I've gone back and modified all my code that involves something moving on screen, to make it move a distance based on the current FPS. The end result, everything that -should- move at a constant speed, actually -does- move at virtually a constant speed no matter how high/low the FPS currently is. In reality, this wasn't much needed for what I currently have (except the GUI stuff), but it was very much so a good practice for me to know what I'm up against in the future when this will start being an issue.

Small graphical pretties: Little tidbits that give the game a more professional look. For example, when you select "load game" at the titlescreen, the load game window appears, and the cursor smoothly (albeit quickly because of how far in needs to move) moves across the screen to the appropriate spot in the load game window, instead of just instantly appearing there. Also, GUI groups fade in and out depending on what's active. Basically each "group" of GUI elements (typically, a window and all the stuff in it, is 1 group) can be in 1 of 3 states: Visible (100% brightness/visibility), Paused (35% brightness/visibility), and Invisible (0% visibility). Whenever a certain group's state changes, it smoothly fades to the appropriate values. This makes it visually very easy to tell which group is currently active, while still being able to see all the previous groups that lead up to the currently active one. Also, a "selection box" that hovers over the currently selected item in a menu (beside the cursor). It is fairly subtle, yet visible enough to easily notice. This box instantly moves to the next item selected, and is animated, while the cursor smoothly moves between items [very quickly]. It just makes it that much easier to pickup which item is currently selected. Got the idea from playing FFXII.

Stuff that is currently only partially finished because I'm waiting for the next release of LTE GE (it has some new functions I need!):

Finishing my custom skin class: The next release of LTE GE will have better support for stretching 2D textures on screen, which will make my life MUCH easier for the last little bits of my skin stuff, such as properly displaying GUI Images (so they'll be cut off when they should be!), and allowing me to finish off GUI Progress bars (currently it doesn't show the "progress" portion, only the border/background!)

Getting rid of the last crash left in the game: The next release of LTE GE will implement some functions to give me better control of which sounds are loaded into the PSP's ram or not. It will make my life MUCH easier (not to mention, make my game much more reliable) once those functions are available to me, to fix this crash. I could do it now, but it would take much work, and once those functions are available, I'd rewrite what I'd written anyways, since they'll make my code more efficient as well, so why bother until then, right?

Stuff currently on the table as my "next features to implement":

Proper method for anybody NOT using a 1.5 PSP to have sound. Right now the game assumes you are using a 1.5 PSP (or thereabouts), and just directly attempts to access the Media Engine on the PSP. On later versions of PSPs, Sony put in more protections and such, and now you need to load a special module to get access to the Media Engine. Not a big issue, except that I've been having sporatic success with loading the module, at best. I'm hoping to find something that works all the time.

Audio skins: In the same way as I have GUI skins, I'm toying with allowing the player to have audio skins as well. It should be relatively simple to implement, should I decide to do it, and all it would really do is give you custom sound effects for each GUI skin. This would be seperate of course, so the player could mix & match GUI skins with audio skins. Just a thought.

Additional Kanji support: Because of the way the LTE GE loads fonts, I have to manually add any kanji I'll need, into my font file. I'd like to go thru the Japanese script I've received from Sky Render (thanks buddy!) and add in at least all of the kanji used up until my intended "first goal" of the game, that being Figaro Castle. Perhaps farther, but I have a feeling that they kinda go all out with their kanji usage, and that would eat up more of my time than it will be worth. I'll look into it.

Script loading: Once I throw together some GUI layout files for the world map state (dialog boxes, etc..), I'll be toying with loading scripts into the game for display via these boxes. I'll likely be writing my own custom script files, instead of directly using Sky Render's, for those curious. I don't suspect this will be that hard, but I'll have to ponder exactly how I want to arrange the memory in the PSP for this. *ponders*

Alternative locations for GUI layout groups: Typically all the GUI layouts are well formed enough that they won't get in the way of the 3D action happening in behind them, but with the dynamic camera action that'll [optionally] be happening during battles and whatnot, some of my pre-decided locations for GUI elements (such as speech during a battle, etc...) may kind of get in the way. This is something I've only passively been thinking on, so it may not make it into the game, but I've thought that perhaps I should write an algorithm for detecting approximately where on the screen the action is taking place, and deciding which (of 2, likely..) place to display certain GUI stuff, when it's supposed to pop up.

Loading bar: I'm pressing for SiberianSTAR to write some functions into LTE GE to better facilitate my ability to put these in, but I honestly don't know if he ever intends to. Regardless, it IS still possible without, it'll just take a whole lot more coding on my part. Despite that the longest loading time so far on the game is roughly 5 seconds, this will very likely be making it into the game, it's just a matter of when.

Some GUI stuff so far...

2007-12-11T05:28:00.000-08:00

Time for a couple of screenshots of the GUI system I've been working on.

This one's nothing great- just the title screen with the GUI visible in a temporary state. I've spent some time on polishing the GUI's functions as well, to give it a more smooth & professional feel: The cursor moves left and right a little bit while sitting at any item, and smoothly moves between items when you select a different one. I'm hoping to soon enable animations on the GUI elements for added special effects.

Note also that the game loads up the most recently saved options at startup, one of which is the GUI skin used, so the title screen's GUI can have different looks based on the GUI skin last used in game.

This next shot is showing off the text input system I've got in place now. It's fully functional, and supports english capital & small letters, all japanese hiragana, katakana, a small subset of japanese punctuation & symbols (which you can see in the screenshot), and is fully extendable to support any japanese kanji I decide to use (likely virtually everything that is used in the original game).

You can also see that the name I've got input already there shows that english and japanese can easily be mixed together, quite unlike most games with bilingual support.

Another thing to note is that all these GUI graphics are tentative. I may or may not be revising these in the future. (More likely than not, I'll be revising the main portion of the graphics for the name input system)

Other notes on the game:
I'd like to give my thanks to SiberianSTAR from www.ltestudios.com for porting this engine over to the PSP. Not only is the engine great to work with, but he's gone out of his way to help make the engine exactly what I need for my game. In addition to that, he's also been kind enough to build me a custom version of the engine that better suits my needs than the vanilla engine.

I've actually been talking directly with Sky Render himself about getting his copies of the direct rips of the scripts from the english & japanese roms.

What's been going on

2007-12-11T05:26:00.000-08:00

What's going on:

For all of October except 2 weekends, I've been in Minneapolis for work. (I was flown back home for Canadian thanksgiving, and then again at the end of the month to take care of personal bills/etc/halloween). So I bought a laptop, and brought it/my development PSP with me, and work on the game pretty much the whole time I'm not working out here. Which is a lot of the time. This is great, because there's no distractions, like at home, to pull me away from this.

I don't have my equipment to give more videos/screenshots with me, but I can at least tell you what I've been working on:

I've got the GUI system virtually complete. In itself, it works 100%, but with any interaction to anything else (changing equipment, etc...), it's not working yet, because I don't have anything implemented for inventories/etc yet on the PSP version. All the GUIs in the game are loaded via XML files, so it'll be easy to create/change layouts until I'm happy.

Also, I've created a new way to input text, for character naming. If a person practiced, s/he'd likely get upwards of 30ish (as a guess?) WPM typing speed, on a PSP^^ But since the only time you type in this game is during character creation, it's not like it's a major feature. Note also, that I can't take full credit for the text input system. The -idea- was somebody else's. I used it once in some other homebrew, loved it, and created a heavily modified version for my game. Like, stupidly modified. Heh.

With that part completed, I want players to be able to name their characters in Japanese, so I'm using this time to implement Japanese support to the game. It's proving to be a slightly more difficult task than I thought, but I think I can get it working well enough, but likely with extremely limited kanji support. At the very least, hiragana, katakana, and english will be supported. I'm not about to create my own Japanese IME for this game. Heh.

Other things I've done aren't nearly as visible: Input management. I can send button presses/analog movements to wherever I want, so the appropriate part of the game can handle it (layman terms: When you press the up button, now the game knows whether it should move the GUI cursor up, or move your character up on the screen, etc..) Slowly creating a custom GUI skin system, to allow the player to select different skins for the GUI (just like the real game!), Improved the intro sequence slightly, to make it more authentic. (there's a couple seconds of a simple FFVI logo at the beginning before the clouds start rolling, etc..) Small graphical improvements. I've been spending a lot of time coding, so much of the stuff I have complete don't look very pretty as I've put some "coder's art" temporarily in place just to make it work, and haven't replaced it yet.

What needs to change in the intro

2007-12-11T05:23:00.000-08:00

It's a fan video just like anybody else's. I have, and will continue to, always give credit to Square-Enix for what they have done. If it wasn't for them, I couldn't do any of this- so kudos to them most definately!

Timing: The original took 18 seconds until the musical clash (and thus, the logo fading in). Because of the song I used for this, I could only edit it down to 25 (roughly) seconds until the musical clash in my version. So yes, a bit longer. It can & will be skippable. When I first created this, I had the SNES song playing, for timing. I obviously wanted a higher quality song, and when I got it on there, I had to adjust my timing in it as well. Haha, I have my SNES with FFIII in it, -right- next to my computer, cause I'm always using it as source material. It is, by FAR, my prime source material for influence on virtually -anything- in my version of the game.

2 Things still need to be done to it before it's really complete:

1) The sound blips. Occassionally you hear them because MP3 playback is expensive. Occassionally the PSP slips up. (it's only got a 200mHz processor!). I'm currently looking into AT3 playback (that is sony's audio format native to the PSP, or something...) Hopefully it'll run nicer. If nothing else, it appears to make smaller files, although I haven't messed with that portion of it extensively.

2) The logo. I want to clean up the logo so it appears sharper on the PSP screen. Right now, it's a scaled down direct rip from ... something. Something off the net- god knows. It's just a temp, anyways. Also, I want to have the logo appear for a second or 2 before the clouds thing starts, as that's what the original does.

Heh yah, this, programming wise, doesn't show off much of anything. I'm aware of that. Like I said, most of my programming time went into the internal framework, recently. This intro sequence is just the initial visual progress I've made with this.

Sources: The song played is a cropped & slightly edited (volume fade, etc..) version of FFVI opening theme (Tina) off of the FFVI Grand Edition CD. The graphics are freely available high res photos available on the net, and HEAVILY HEAVILY modified for the game. I -was- gonna take these shots myself, but we never get cool clouds like that here, and setting up a system (although not hard...) to take photos of lightning is kinda a lost cause here-- most of our lightning is up inside the clouds, and just appears as sheets of brighter clouds (read: boring!)

Let's visit PSP-land

2007-12-11T05:19:00.000-08:00

Okay, I'm back! And good news to all: I [nor the project] = NOT DEAD!

I took a bit of a break for a while there, as my work was getting all crazy (got a promotion/huge raise, started working 10hr days, learning new responsibilites, etc.. = STRESS!), but things have calmed down a lot, and I can concentrate on this a lot more now.

Remember that the shots I showed you of the model are completely untextured. The hair, and other parts, will have a lot of transparency applied to it, and will definately look more detailed/curly/etc.. That applies to her eyelashes/eyebrows as well. That also says that her skin color is only a rough approximation, as these colors you see now will have ZERO bearing on her final color composition.

And yes, I realize this is one helluva road I've got laid out ahead of me, but hey- I love what I'm doing, so I see no reason to grow tired with it anytime soon^^

Official art I'm looking at, is generally the original stuff by Amano. Otherwise, I'm typically going by what the game itself originally looked like.

I currently have no plans for voice acting, battle sounds are up for debate. I haven't really given huge amounts of thought to the sound portion of things, to be honest with you-- but I think it likely that I'll be creating new ones, as the old ones are just so .... old.

I currently do not have a site for this project-- I guess the closest thing I have is this forum, at least for the time being.

I've been biting my tongue for the past week or 2, despite how much I've wanted to share with the world, but now I feel it's finally time to tell people about the latest developments in the FFVI3D project. First off, it has now been renamed to the FFVI3DPSP project. 3 guesses as to what's changed, and the first 2 don't count. Hell, neither does the last 1.

My game is now being ported over to the PSP. (For those who don't want to ask a silly question, that's a Playstation Portable^^) This also means a change of engine, which I've also been dealing with. That said, I am now no longer using the Ogre rendering engine. Don't get me wrong, it's an AMAZING engine, but it's uhm... overkill, for what this game will require. I'll definately keep it around for other projects tho, I love it to bits! The engine I'm now using is called LTE game engine. It's a PSP conversion of the wellknown "Irrlicht" engine for the PC. Since this is a (semi)fullblown GAME engine, instead of just a rendering engine, it'll also save me LOADS of time programming things, such as a sound driver, etc..

So, in the last 2-ish weeks, I've been porting my game into the LTE engine, and at the same time, porting it over to the PSP. All is going well, it's just taking time. I have a lot of the internal framework done now, and have started on something you can actually SEE. This is where the fun comes: I've recorded a video of me booting up my PSP, and playing a teaser trailer of my game. This serves 3 purposes:

1) It proves it's on the PSP.
2) It gives you some eye candy (yay!)
3) d^-^b

So anyways, without further adieu:

High poly-count Terra

2007-12-11T05:14:00.000-08:00

Okay everybody! Time for an update with screenshots! *dancemonkey*

These are some preliminary shots from in my modelling program of thy HQ version of Terra. This is the model (plus or minus) that I'll be using for cinematics (if I do any), and for the normal map that'll be used in game.

Please note that this is not shot from within my game engine yet, as there's still a LOT of work to get it in there, but at least now it's mostly built!

Some issues you may see, that I am aware of, and why they exist:

1) There's no textures!
A) That's right. Just colors that approximate the textures.

2) You can't see her eyes very well with all that hair in the way!
A) Once textures are applied, her hair will have a LOT of transparency, so her eyes will be WAY more visible.

3) There's kinks at the joints!
A) Correct- that's what you get for quickie-I-wanna-get-it-out vertex weighting. The kinking is the most noticable in her hair. This will be fixed, but for the time being, I just wanted it to work, perfect or not.

4) Her shoulderpads are too big!
A) Yes, I realized this as I started posing her for the shot. Rest assured that they will be revamped A LOT before she is finalized.

5) These are only shots of her upper body!
A) Yeah, currently having issues with her legs going thru her dress-- not to mention the mess of things she has around her waist. Was too lazy to fix it before putting some shots out there.

6) There's a floaty thing in the background!
A) Yup! Just to make you ask questions! It's some of the trim for the arms of her dress that I haven't weighted yet (so it doesn't move with the rest..)

6, version2) Her eyebrows/eyelashes are solid!
A) Yah, again, with no textures, there's no transparency, and thus, the eyebrows/eyelashes look kinda bulky.. ;p

6.. again...) You took too long!
A) Tough pickles.

And so, without further adieu, les shots.

Project origins

2007-12-11T05:03:00.000-08:00

This project started somewhere near the beginning of the year... *checks first post* Whoa- Feb 11th 2006. Not bad, me! *pats own back* But that's just this thread-- the actual project started right at the beginning of my xmas break from work, so that was somewhere around ... *looks at calendar* Dec 23 2005, or thereabouts. ^-^d

Odds are, no- it won't be put on a site for public availability. I may be making available small portions for outside bug-testing tho. But for legal reasons, unfortunately, I'm not sure if there's much of anything [at all] I can do about making it available to everybody. But screenshots, movies, etc... So long as I give all the appropriate credit, I'm pretty sure are allowed. (Correct me if I'm wrong..) I should call up my lawyer friend and ask him about this stuff... hehe ;p

Haha! Square-Enix might ask me to be on the team?! That, I could only dream about *dreams...* But I guess my learning Japanese would be a bonus in that respect ^^;

Pretty soon here (within the next week, I hope) I should have some shots together of a physically complete high quality Terra. I'll still need to do up the textures at that point tho. She currently has flat colors applied to her various parts, so she looks vaguely correct from a distance, hehe. But I'll be releasing some shots of her before texture application. This model is intended to be used for any pre-rendered cutscenes I decide to do (___IF___ I decide to do some...), and also for the normal mapping I mentioned earlier, a technique that makes low quality 3d meshes look higher quality than they really are.

Upon release of these shots, (in which she may or may not actually be "posed") I'd like some constructive criticism to help improve her-- not so much to make her realistic/etc.. but to make her accurate, for the most part. I'm pretty happy with the realism/anime influence balance that I have for her, so I think little will change in that respect.

Also, now that school's finished, I'm acquiring more and more of that free time I had lost near the end of the semester, which is great! This model's been speeding up in it's progress, and once it's complete, I'll be jumping head-first into the coding again to pick up where I left off (somewhere around trying to make the battles work, I think... Or maybe it was towns?)

Let's see some REAL 3D! (teaser)

2007-12-11T05:01:00.000-08:00

Okay guys, I've been holding out on this for quite a while now, because I wanted to put a whole bunch of this stuff together for my next post-- I've finally managed to put enough of it together to give you guys a quick preview of what I'm currently working on for the game. As you can obviously see, it's only a development shot, but it'll give you an idea of what's been going on, etc..

Take note that this is a high quality model, and isn't what's actually going to be used in the game (although I'm going to use some rendering tricks to make you think it is!), so don't start thinking that you'll need a god machine to run it. Maybe a good machine, but not a god machine.

Artistic vision

2007-12-11T04:59:00.000-08:00

Okay, update-y time guys! Sorry about waiting so long, but even now there isn't a huge amount to report. Mostly just want you guys to know that the project (nor I!) isn't dead!

Not a lot updated on the functionality of the game, the time I've been spending on the game has actually been on taking a lot more serious standpoint on the graphics. I've done some concept art of my vision of Terra, and I'll be using that as my base for my new model of her. Here's a quick digicam picture of one of the pages:

Also, I'm looking -very- closely at the detail levels used on the models in Dirge of Cerberus & FFXII, and am using that as a target level of detail, for those interested. Yes, I know they're not out in North America yet, so you'll likely have to check out screenshots or something, but to really see the details, you'll need to play the games and see how amazing the models (especially the faces!) are when a cinematic zooms way in. (I'm talking in-game models, not FMV models..)

'Course, that's about all I have to show right now... Japanese class has been pretty heavy, what with a midterm just recently finished, and our teacher cramming the final chapter for this semester down our throats as fast as possible to have as much room as possible for review before finals (and the final presentation I need to prepare!)... I'll have more time once the semester is over, but at least I still have -some- time right now^^ So I'm using what I can for graphical components and such, that don't involve sitting down for hours at a time concentrating on one thing uninterrupted.

Let's look at where we are...

2007-12-11T04:54:00.000-08:00

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 mouthful.. 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

I loads Quake3 levels!

2007-12-11T04:53:00.001-08:00

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...)

Script thoughts

2007-12-11T04:49:00.000-08:00

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.

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!)

Time Frame

2007-12-11T04:48:00.000-08:00

Honestly, I haven't a clue how long this will take. 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 a measurement in years 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^^;

What's difficult in game programming?

2007-12-11T04:38:00.000-08:00

IMHO, the "game-mechanics" portion is the EASY stuff (it's just simple math..). Especially in regards to an RPG type game, where the most complicated math you have to deal with is multiplying or dividing by 4, heh heh Regardless tho, I already have a good portion of that done already, but I decided I wanted something more visual for me to debug with, so I'm trying to get a simple viewable version of the game functioning to view things with, instead of lurking in the debugger, sifting thru variables;;

I've actually found that the hardest parts of programming the game are:

1) The 3d math for ... well, anything 3d, really. Heh. dotProducts, crossProducts, rotational trig, quaternions... a little more advanced than the [generally] adding/subtracting/multiplying/dividing required by the calculations of stats/damages/etc.. Really, mathematically speaking, I'm pretty confident that FFVI is incredibly simple.

2) The "behind-the-scenes" classes & objects that allow the game to run properly, and efficiently, fully encapsulated in their own little black boxes (or at least, that's how I like my code to be...). Things such as a game state manager (it changes the rendering mode, input allowed, etc.. depending on the state you're in, such as title screen, world map, battle, town, menu, etc..), an input stack with bindable keys (so when you press a keyboard key, it checks to see if the user has changed the use of the key, then asks a stack of items what to do with it, and each item in the stack checks to see if they can use it-- if not, they pass it on to the next item in the stack), and finite state machines (typically for AI, you change variables in each "machine" as the game runs, and the machine calls an "update" every frame, and calculates what it'll do based on how the variables in it have changed).

I'm willing to go into more detail about how these things work, if anybody's interested, but I just thought I'd point out [what I consider to be] some of the more complicated parts of programming a game.

The lighting on the model in the world currently is screwed, because I don't have lights in the world yet, and the default brightness for the model & the terrain are completely different values. So Terra appears to be -way- too dark right now. I'll get around to those lights later.. probably much later- but I might change the default brightness level, cause that's been bugging me..

Terra textures

2007-12-11T04:33:00.000-08:00

I have enough experience making models that I have a pretty good idea of how to lay out a texture for it before mapping the UVs to it. It's pretty easy to guess, once you're used to it, actually ^^v The majority of the time, for humanoid models, the texture layout'll be the same. Of course, occassionally I may be off on some detail or some such, and that's just a matter of tweaking the texture afterwards-- no big deal^^ I'm constantly tweaking my textures anyways, which is why it's a great idea to always use a format that DOESN'T embed textures into the 3d mesh, whenever possible.. at least, such is my humble opinion...

In the case of this project (at least so far), the textures for the characters (all 1 of them!) are ripped directly from screenshots of them in the FMVs-- here's a shot of the texture I'm using for a portion of terra currently, to help illustrate my point.

I'm not sure when/if I'll be accepting help for this project, but I'll note names down *nodnod*

On a semi-related note: I'm planning to go thru and [likely] completely rebuild the terra model/texture from scratch soon. We'll see how that goes later tho. Right away, I'm hoping to start implementing a Quake3 BSP loader for battles, and possibly other parts of the game. *cheer*

I'm planning on giving her the greenish hair colour. I was always a fan of that (and it's easier to tell her and Celes apart at a distance that way). Mmm green hair^^

The image I posted last is the -actual- texture file currently being used for her hair/face/upper chest, so yah, green hair. As you can see, I've already gone thru and gave it some green hair on the most part of it (still gotta work on the bangs, but this isn't decided as a final texture for it yet, so I won't waste the effort until I'm sure...)

It was pretty easy to manipulate the colours, I just used the pen tool to define an area to work in, set it as the selected area, then adjusted the variations to give it the green look^^

Yes, it's definately gonna be a challenge to manually do everything without a terrain generator, heh. But I'm actually -really- looking forward to building the towns/battle scenes! Because they're (at least currently planned to as...) going tobe in the Quake3 .bsp file format, so I'll be able to use QERadiant, or some flavour thereof, to create the scenes. It'll bring back memories of making levels for a mod group I was working with thru Quake2/3. *remenisces*

Model creation workflow

2007-12-11T04:32:00.000-08:00

I'm using Milkshape3D to create the objects, but I have a custom exporter for it to export the objects to the .mesh/.material/.skeleton file formats used by the rendering engine.

My texture alignment is being done in DeepUV.

It's actually a strange pipeline for my objects:

1) Create the 3d mesh in Milkshape3D
2) Create the texture in Photoshop7
3) Create the material/apply the texture in Milkshape3D
4) Export from Milkshape3D to .obj format
5) Import .obj file into DeepUV
6) Align textures properly
7) Save .obj file in DeepUV
8) Import .obj file in Milkshape3D
9) Save file as new updated .ms3d file (for future alterations)
10) Export to .mesh/.material/.skeleton files for use in-game.

That's roughly it. Not as bad as it sounds, once you're used to it.

About my first (temporary) Terra model

2007-12-11T04:29:00.000-08:00

I'd -like- to do more than just the beginning stuff, but for the beginning, I'll be doing the beginning stuff... to begin with. begin. ^^

I'm actually mostly concerned with the model itself. You know, the overall look of her. As you can see, what I currently have is leaning a bit towards realism. Should I stay in that direction, or should I anime it up a bit? I'm mostly concerned about anime-ing it up a bit, because I'm thinking about some of the animations the characters do in the original game, and how downright silly they may look on a realstic-esque model. (such as bug-eyes, and their oh-so-cute laughs...) Her pose is 100% temporary and only there so she's not standing with her arms out at shoulder level (default position).

Thank you for the feedback on her regardless-- but if you have something to say about her general looks tho, I think that would be more immediately useful to me^^

The characters in game all run on skeletal animation, so to change her position, it's just a matter of positioning the bones better. The bones were just slapped into this position so she doesn't look like she's doing some gymnast landing pose while saying hi ^^

For her clothing: The dress material, I slapped together from an asian dress swatch. Her Belt and sash are actually ripped directly from a screenshot of the opening FMV, and the leggings I just threw together really quickly so she had something (_DEFINATELY_ getting done better later..) Her boots & shoulderpads are also directly ripped from a still of the opening FMV, as well as her hairpiece, earrings, face, and shoulders/neck area. Fairly heavily modified to remove FMV shadows, etc.. (since my game will have realtime raytraced shadows of it's own..) Some of the textures need to be redone, and the material scripts they use ALL need an overhaul (if for nothing else, to support lower-end graphics cards..)

As far as _HOW_ I managed to align it all right, that's a topic of it's own, and worth looking into if you're a modeller-- just look around for tutorials on "wrapping textures" or some such... There's programs dedicated to such tasks, as the generic unwrappers provided in most 3d modelling programs just aren't versatile enough.

New additions

2007-12-11T04:25:00.000-08:00

I'm going to have to be working on some MagiTek soon as well, seeing as it's needed for the first scenes in the game. I'm actually quite looking forward to it, as I find technology to be easier to model than organics. Been wanting to do some MagiTek for a while anyways^^

I have way too much work for me in the future-- it's great! I love doing single-person jobs like this.. it just feels so good once you've got something to show!

I'm using an old copy of Milkshape3D I got back in the days of modelling for Quake2 for my modelling/animation, and I'm using a commercial program called DeepUV for my texture UV wrapping. For the actual texture creation, I'm using photoshop7. Much of my textures for the characters are actually creatively wrapped still frames from the FMVs that came with FFVI in the anthology release. Tomorrow, I'm hoping to have some more camera options implemented, and I'll be able to take a decent shot of terra (and her speech window!) You won't be able to see it in the shot, but she's running some temporary idle animations, and she even blinks! ^^v Anyways, I'll be shooting for tomorrow, but we'll see how that goes..

I have this gift (or a curse, if you will) to always manage to balance everything I need to do fairly well, and have plenty of energy to undergo all said things... but it comes at a cost. It costs me my sleep time. (Always the first thing to go... ~sigh~)

My "life" tends to be limited to the weekends. More specifically, saturday nights, at the bar, for like ... 2 hours. Generally speaking *grin* But shhh! Don't tell anybody, 'lest the programmer's union confiscate my computer for disloyalty *shudder*

Agreed on the job thing tho, even tho I'm not a coffee drinker-- I need the money for the BlackBlack gum (Japanese caffeinated gum) ^_^v

Update on my game: Last night I implemented Japanese support, so now the characters can talk in their native language! I'll probably take a shot of terra speaking Japanese instead of english, when I do that shot up. And right now I'm working on a keybinding mechanism that'll allow the player to remap keys if they don't like my default settings (but who wouldn't like that!?!? hehe)^^

Okay, here's that shot I've been delaying.. this shows off some of the interface I've done up for it that I'm rather proud of, and you get to see Terra's current form as well, with a nice lil mountain in the background.

I'm not very happy with how Terra currently looks tho, so I'll probably be redoing the model sometime soon. I want a semi-realistic look, but still anime-esque enough that the characters (and their animations) can retain some of their original style from the original game^^

Enjoy! I'm off to finish tweaking the different camera modes I just put in^^

Specs and Legalities

2007-12-11T04:18:00.000-08:00

The great thing about the Ogre Rendering engine is that it's configurable to use both OpenGL & Direct3D... I believe those screenshots were taken when I was loaded up in OpenGL mode tho.. I'm not a big fan of microsoft (but let's not get into that here...)

That terrain was a temporary one that I just threw together to have _SOMETHING_, and the end project will NOT have that particular one in it. As far as the textures go, it was using a splatting shader to put the different terrain textures on based on height in the heightmap. There's about a billion (plus or minus) other splatting modes available, but that's the one that I used for taking the screenshots. I'll decide at a later point just what it is that I'll settle on later. Maybe make it user configurable (especially if I want to use the shader).

I'm kinda shooting for a middle range/high end computer setup to play the game tho. I really detest having to limit myself because some guy on a 386 wants to play HalfLife2 on it. I'll be putting some fallback rendering techniques in for the textures and whatnot, if, for example, your video card doesn't support certain features, tho.. But those aren't implemented yet.

I'll likely be putting in a skydome, although a skyplane might happen.. We'll see. No need for a skybox tho, as the player'll never see that far down, even in the airship. I haven't even TOUCHED the sky yet tho. All I did was set the background colour to a pretty blue^^

Music: I'm thinking about using either FMOD or OpenAL, but really, that's not high on my todo list yet.. I want to make some other important things work first. If I can start using the orchestra music on various CDs, it'll likely have to be MP3 format. I haven't even thought about the legalities of releasing it to the general public yet-- odds are Squenix would have my head heh heh. I'll concern myself about distributing it (if at all) when it's somewhere even remotely close to being complete-ish. As far as total project size so far: Currently it's sitting at almost 100MB, but 50MB are temporary files, so in reality, it's currently 50MB. This is with no texture compression yet, which'll be end-project once they're concrete. The majority of my other data files are 1 or 2 digit kb sizes. Although a couple of the dlls are a little heavy at 1.5MB and such... but once I've decided for sure on what I need/don't, I'll be removing some of them.

Usually, my music composing has been in fruityloops, which I've quite enjoyed. But I'll worry about my music and whatnot later, when I get even within SIGHT of that bridge. :)

Well, the big thing about this project being a remake in 3D is that I want it to be all in 3D. I'm toying with the idea of allowing the player to swap out models for sprites in the majority of situations, but we'll see if I actually decide to go thru with it.

I already mentioned earlier that I'm using the Ogre engine, hehe. Ogre is released under the LGPL license (http://www.gnu.org/copyleft/lgpl.html), which basically means (and I quote) "You can get the full source for nothing, nada, zip. There IS such a thing as a free lunch."

LOD was something I'm capable of doing myself (and have in previous projects), but conveniently, it's already fully integrated in Ogre. So, no point in reinventing the wheel.

Soon, I'm hoping to implement an in-game screenshot system, possibly with timestamps (in the name), so you won't have to deal with my ship-shod image cropping skills of doom in too many more future screenshots ( ^-^)

Some first-release screenshots

2007-12-11T04:15:00.000-08:00

Never used imageshack before-- I love how easy it is to use!

Anyways, here's a shot of the titlescreen:

And another shot of my heightmapped terrain. This terrain is created entirely from a single 2 dimensional image. Also note that although you can't see it in static images, the terrain is "paged"-- for those of you who don't know what that means, paged landscape is a term used to describe landscape that's divided into pieces, and only the pieces that are close to the camera are loaded. So as you move the camera forward, terrain 100' behind you unloads, while terrain 100' in front of you loads. Very useful. It also has LOD (level of detail) morphing. So as the terrain gets closer to you, there's more detail visible to it, and it never "pops" between detail levels.. it programmatically morphs between the detail levels.

Like I said, I've only been working on it since just before Xmas, so really I don't have much yet;; I have a shot of my GUI showing off Terra speaking, but the terrain in the background (and the 3d model of terra) are kinda screwed up looking, cause they were a little broken at the time. Once I get my current code into a more workable state, I'll take a shot of terra talking for you guys tho, so you can see my speech window.. even if you can't see it in "action" (it fades & grows as it appears, just like the originals... and you see the text scroll in at a configurable speed)

2007-12-11T04:09:00.000-08:00

I can understand everyone's thoughts about lack of proof, but I want to hold back on too much of the screenshot-iness until I have something more visual to show off. most of my programming thus far has been more internal stuff, such as game states, multi-camera managers, custom file format loaders, and implementing a GUI worth seeing, as well as various other minor tasts such as loading screens, the title screen (which doesn't look too bad right now, considering it's temprorary-- maybe I'll post a shot of that, at least...), and a heightmap renderer for the overworld map.

As far as keeping it quiet is concerned, I'm not OVERLY concerned (although I don't want to be cocky about it...) As I said, I've no desire to be marketing this in any way (as I have no rights to .... pretty much anything), and even if they do manage to put a stop to it publicly, I'm determined enough on this project to continue to develop it for myself, if nothing else.

As far as the considerable work is concerned, it's a free-time project, so it's after work and on weekends and such... so I guess you could consider that a considerable amount of time, especially when it gets more to the 6-months-since-starting mark.

I'm programming in C++, and partway thru the beginning of my project setup, I ported over from VC++6.0 to VC++Express. (I'm aware of some quirks about how to distribute executables from that environment, no need to warn me on that, heh^^)

I -was- working on my own 3D engine with my last project, and it was coming along nicely enough, but I quickly (if you define quickly as 2 years) found out that if I ever wanted to actually get to work on my _GAME_, I couldn't be focusing so much on the engine. And if I didn't focus enough on the engine, it wouldn't be capable of doing what I want it to. End result, use a currently-maintained free engine. My engine of choice: Ogre. It's only a rendering engine, not an entire game engine, which is exactly what I want.

Although, one thing I was curious about recently, is where EXACTLY are the boundaries for the different "zones" of enemy formations on the world maps(s)? I've seen small (read: minimap) versions, but I'd like something like an overlay on top of a 1:1 worldmap... Like I said, I want this to be retardedly accurate, as far as the internals go. I'm even going so far as to program in the original glitches such as psycho cyan, etc.. (But I'll be including an option to "patch" them up, which will by default be on)

My programming background, in 1 sentence: I started programming, myself back in highschool, but the teacher knew nothing about it and thus was unable to teach me anything in the class, and as such, I was left to my own methods, so since then I've been making many small projects and whatnot, mostly for personal reasons/family/friends, and whatnot, so as to improve my skills up until the point where I am at today, which would be the age of 24, and having various small apps/games/etc finished (and more unfinished) distributed to various friends & garbage cans, and really aren't very available anymore, not that I care very much, as this is definately my most important project to date. (Okay, so it was 1 _LONG_ sentence)

Now, let's see what I can do about a screeny or 3...

First public announcement redux

2007-12-11T04:06:00.000-08:00

So first off, I'd like to take this moment to introduce myself to everybody: Hi, I'm Nyxojaele- I live in Canada and have a boring job, and in my free time, I've found myself spending copious amounts of time developing video games and whatnot, instead of playing them. My computer knowledge is entirely self-taught, and I like FFVI too much to be considered healthy. Anything else you wanna know, feel free to ask^^

Beginning stuffs so nobody complains it wasn't obvious enough:
THIS GAME IS CURRENTLY NOT INTENDED TO BE RELEASED TO THE PUBLIC. I DO NOT KNOW IF IT -EVER- WILL BE. MY LAWYER AND I ARE LOOKING INTO IT, AND WHEN WE HAVE A FINAL DECISION ON THIS, YOU WILL BE THE FIRST PEOPLE TO KNOW ABOUT IT, POSITIVE OR NEGATIVE. CURRENTLY, THE SITUATION IS GIVING ME REASON TO LEAN TOWARDS _NOT_ RELEASING IT.

I HAVE NO DESIRE TO PISS OFF SQUARE-ENIX (I LOVE THEM!), SO I'M TRYING MY BEST TO MAKE SURE THAT ALL OF THEIR INTERESTS ARE LOOKED AFTER, -BEFORE- MY OWN. I RESPECT THEM A GREAT DEAL, AND HOPE THEY ARE WILLING TO TREAT ME WITH A SIMILAR AMOUNT OF RESPECT.

ALSO NOTE THAT MY CURRENT GOAL IS TO ONLY MAKE A SMALL PORTION OF THE GAME. I'M THINKING SOMETHING ALONG THE LINES UP "UP UNTIL FIGARO CASTLE", OR THEREABOUTS.

I've decided that I'm going to start accepting outside help in a limited capacity- since I seriously want to finish this, I'm going to focus my own efforts entirely on the programming aspect- which'll mean that I'll need some outside
help for other things.

Basic NDA/Disclaimer that must be agreed to if you want to help (a more detailed one will be available on request, after I've put it together...)

* Recognize that this project is still intended to NOT be publicly released unless we receive explicit permission from Square-Enix themselves. I reserve the right to be in control of communications in this aspect- with feedback from other group members.
* No outside advertising for this project that hasn't passed by the Nyxojaele filter. I still maintain this as my own personal project, so I don't want somebody else going on about it behind my back.
* Works for this project shall be entirely original and created specifically for this project. You still retain your rights to the works, but are not permitted to use them for "other projects" (personal portfolios etc are fine). Additionally, full credit will be given for all works. Please note that it is not acceptable for ANY works to be downloaded from elsewhere- they must all be original works to which you hold the rights.

Positions where help is specifically desired right now:

* Concept art- Skilled art that maintains the same "feel" as the original game held is desired. Taking influence from (although not duplicating) Amano-sama's art is perfectly fine. Attention to detail is a must.
* Sound effects- High resolution recording of sound effects is desired- we can downsample later, but can never upsample for an increase in quality. Creativity is a must- how else can one create sound effects? Proficiency with an audio alteration program a plus.
* 3D models- Skill in both high poly-count & low poly-count in-game models. Cinematic poly-count model skills a plus, but nowhere near necessary. Cinematics will only be added to the game if a sufficient skillset can be acquired for the team.
* 3D levels- Architectural eye a must. Ability to create full 3d models of the original locations found in game- attention to detail a plus, but since this may be on PSP, we might have to budget our poly-counts.
* Texture artist- Skill with high quality, low/medium resolution textures- we don't want to be using up boatloads of memory for just textures.

These are just the currently desired positions for the project- if there's something else you think you can offer that will benefit FFVI3D, then please post here and let me know and I'll see if it's a viable option.

Since shortly before Xmas, I've devoted my game development time to a new project-- I'm remaking FFVI in 3D, using a freely available, well-maintained 3D engine. I have no desire whatsoever to ever market this or anything, but I'm hoping for a commercial quality game here, folks^_^v

Short of any research I'm doing into things, virtually everything is being done by myself. I do all the programming, 3d modelling, GUI graphics, etc.. The only things that aren't done by me (currently, this may change!) is the textures used for the characters, which are ripped straight out of the FMVs that came with the FFAnthologies re-release of FFVI, so as to preserve as much quality of the original characters as possible. Anything I couldn't pull out of those videos, I've made by hand myself. And altho there currently isn't any sound as of right now, the current plan is to remake as many of the sounds as possible, myself, and use the original (or orchestra!) music from various FFVI CDs... possibly going so far as to redoing the music entirely in my own (not drastic!) flavour.

My current goal with this project is to have a fully functional game for the first 1hr of gameplay MINIMUM. That means that anything that a player would logically expect to be able to do (and more!) in FFVI in the first hour, or thereabouts.. which means I'm going to have my work cut out for me as far as content goes once I get the programming in place;; Anything beyond the first hour, I will consider a bonus, and definately a worthy secondary goal.

Also worth noting is 2 more things: 1 being that I want the player to have the option to play in as classic a style as possible, for the old-school inclined, but also the option to play in a more up-to-date 3-dimensional manner, with moving cameras for cinematics, chase cams, and physics effects for some of the battle stuff. The other being, that I want all the internal calculations to be as accurate as possible as well, so I'm modelling those algorithms off of the original maths used, as posted in a couple of the major FFVI rom hacking documents released by prominent names on the subject.

So, those are the details, now for part of the reasoning behind this post (besides this being the first official announcement of this project that I've made..) I'd like to formally request some feedback on this project, in a general sense, as well as any helpful pointers as to where I might look, or who I might talk to, about a lot of the theoretical & internal information about the game.

I've already acquired myself FF3usME.exe for viewing a lot of the info, found complete in game world maps of both WoB and WoR, and have bookmarks of most of the really major sites about hacking the rom (such as Master Zed, Lord J, etc.. I'd have to hop onto my other computer to get a complete listing), and have my own personal notes about various aspects of the game as well.

I'm pretty confident about my resources, but I'm open to anything I may have missed, possibly some obscure ones.. But mostly what I'm looking for is some feedback/thoughts on the subject of my project.

Thanks~

ps. As a sidenote, I've been toying with the idea of possibly upkeeping a blog or something about the progress of this project, but I'm not sure if I'd be wasting my time or not. Thoughts on that?

Initializing...

2007-12-11T04:03:00.000-08:00

Having just signed up for blogger, I now have the wonderful task of moving all of my update content from it's current location (a forum thread) to my newly created blog- this will prevent my fellow bloggers from having to filter thru a rather messy forum thread to read all the previous posts I'd made at the beginning of this project.

Note that these are almost all going to be copy + pastes from the forums- I'll try to remove all personal comments and rework my grammer to feel more blog-like, but please understand if I miss anything. Also note that some of my posts will be a combination of a couple different forum posts, so it might seem weird that I'm talking about doing something tomorrow, and then actually doing it, all in 1 post.

Please be patient, this will take a while.