gbadev.org forum archive

So basically, after doing a fair bit of work, I realized that my ideas simply weren't enough for making even a small demo of a sequel to FFIV on the GBA. That is, my programming ideas. :P

What my plan/outline was, is something like this:
The game's main characters are Cecil, Rosa, Kain and a character that still needs a name. The fifth character may be swapped out throughout gameplay, or whatever; not really picky.
It starts off 12 years later, after Damcyan was fully rebuilt. While they were building, they hadn't realized that they had built a resort/thing on a new island to the left, namely Onigashima. Only after the construction, the people started to see strange things, such as people being murdered, but when they arrived, they were no longer there, and seeing threats in an encoded thingo. As soon as the news reach Baron, Cecil fears the worst and heads to Mysidia. Once there, he asks the Elder of Mysidia if he knows of any legend regarding to this. Upon being asked, the Elder says something along the lines of saying his prayers and enters a battle with the demon that launched out of him. Cecil and the party defeat the demon, after which the Elder is left agonizing and tells them that the prophecy of Xuan is true and is being fulfilled now. He doesn't get to tell them the prophecy and so they set out on a journey to find clues and find out what's going on.

Ok, enough story telling cos I have yet to come up with the rest. :P

I can provide a battle engine, music, music player/sound mixer, sounds, sound effects, graphic effects, and lots of help to those who need it.

So I was wondering if anyone was interested in helping me make this FFIV sequel, Final Fantasy IV-2 - Dawn of Darkness?

I would prefer that it be coded on the GBA as I'm much more familiar with it but can be slightly flexible on that aspect.

EDIT:

I can actually write up a lot of the engine, if not most of it, it's just that I need a bit of motivation.
_________________
I'm 18 and have Asperger's, so if I don't get something at first, just bear with me. *nod*

Aw geez, cue the discussion about whether a small homebrew team can complete an RPG or not.

Ruben: I wish you the best of luck, but what you're talking about is a HUGE project that will take you years.

The failure rate of these projects is high enough that you'll likely not get a lot of takers without a whole lot of demo code/art/engine/something to indicate that you might actually finish, unlike every other person coming here with a similar idea.

My suggestion: get the engine working, even if it's a bit simplified and has ugly art. Create tools for level/map/script editing, and make the first town and dungeon. When you get that working, it should be pretty easy to find a few other people that will get excited enough about your project to help with the rest of the art, level design, etc.

Sure thing.
When I make the engine thingo with the test map[s], should it be in a single binary or multiple binaries?

EDIT: Or single binary with multiple demos in a single menu?
_________________
I'm 18 and have Asperger's, so if I don't get something at first, just bear with me. *nod*

If you really want to do a modified FFIV, you will be better off reverse engineering the FFIVadvance ROM and then modifying it. It already has an engine that supports all of FFIV's features. =) Also, there is a fair amount of documention out there, more for the SNES version than GBA version. Evidently customized SNES versions exist.

If you really want to do an RPG from scratch, do something original. And strip down your requirement to the point where you can complete your game. Something on level of FFIV would 5 ~ 10 years to complete alone, if you have the skills to do everything yourself.

If you can pull off a demo, just make it user friendly and extensible.

Nah, I'll start it from scratch.. I know it can take years, but I still like programming. :P

Anyway..

I'll continue coding the demos tomorrow.. I'm freezing, it's 2am and I've got school in 6 hours :P
_________________
I'm 18 and have Asperger's, so if I don't get something at first, just bear with me. *nod*

Ruben wrote:

Sure thing.
When I make the engine thingo with the test map[s], should it be in a single binary or multiple binaries?

EDIT: Or single binary with multiple demos in a single menu?

Doesn't necessarily matter -- whatever you're more likely to actually complete. My point is that we currently don't believe you'll finish. You're job is to convince us that you will (by showing us partially finished work).

I'd expect you'd need to put in 6 months to a year of work before you'd have a demo that would convince anyone -- a simple tiled walkthrough of a static map with no interaction (like the 700 rpg demos that already exist out there) isn't convincing enough. Neither is a title screen and menus. Or mockups/sketches of possible art. Or your proposed plot.

What would be convincing is an engine that lets you walk around and talk to people, where you have random monster battles that actually work and are playable. On top of that, have an easy-to-use tool that lets your team make their own maps that integrate seamlessly with your engine. When you have that, you might be able to start convincing people to help.

In other words, your overworld engine needs to support map jumps, displaying messages and random battles. Your battle engine needs to work. You need to be able to switch between the overworld engine and the battle engine. You could probably make something interesting enough with just that, so you could probably hold off on the menus and status screens for the demo.

"support map jumps"

As in changing maps?
_________________
I'm 18 and have Asperger's, so if I don't get something at first, just bear with me. *nod*

Ruben wrote:

So basically, after doing a fair bit of work, I realized that my ideas simply weren't enough for making even a small demo of a sequel to FFIV on the GBA. That is, my programming ideas. :P

What stopped you from making a demo? Your ideas or writing the code?

I suggest you take a look at Liran's Tales of Dagur homebrew RPG for the DS.

It might also be worth taking a look through the gbadev RPG demo's. There is some source in some demo's.

It might save you some time to look through some existing engines and perhaps even modify them for your own game (with permission from the original author of course).
_________________
Warhawk DS | Manic Miner: The Lost Levels | The Detective Game

Last edited by headspin on Thu Apr 30, 2009 4:17 am; edited 1 time in total

headspin:
It's just I kinda ran out of motivation, cos I wasn't sure if anyone would actually be interested in even playing an FFIV sequel.
_________________
I'm 18 and have Asperger's, so if I don't get something at first, just bear with me. *nod*

Ruben wrote:

headspin:
It's just I kinda ran out of motivation, cos I wasn't sure if anyone would actually be interested in even playing an FFIV sequel.

I don't think you will have much problem getting people interested the main problem is getting people to take your dedication and skills seriously. As other people have said the best way to do that is with a working demo/engine.
_________________
Warhawk DS | Manic Miner: The Lost Levels | The Detective Game

Ok, so far, everything seems to be going smoothly, so far:

If you want to design maps, you can make them in Mappy, using 16x16 tiles, and either 256 colours or 16 colours. You can make it as so the map can wrap around at the edges and continue (for example, the world map) or just have a fixed tile fill in when you go over. You don't have to export anything; just send me the FMP file and I'll do "the magic." Tested and working.

Music can be written in any sequencer that supports Midi export.

Next on the list: Entities and interaction with other entities.
_________________
I'm 18 and have Asperger's, so if I don't get something at first, just bear with me. *nod*

Yes, map jump as in changing maps. These ultimately boil down to changing to a specific x and y coordinate on a specific map number. As for the maps themselves, the simplist way of doing things is the really old school way:
*) 2 layers, one below the PC/NPC sprites, and one above them
*) attach hit detection and other map attributes to the tiles in the tileset
*) have the PC/NPCs interact with only the lower layer
*) drop scripted events on specific spots on the map

Here is an example. First, tileset attributes:

Code:

Tileset Flags
# Wall, Can not enter
. Land, Can enter
@ Land, Can enter
= Land, Water, Can enter (a bridge)
~ Water, Can enter (but only if you have the means to do so)

Next, a map made with them:

Code:

MAP001 (bottom layer):

0123456789

0 ####~~####
1 #...~~...#
2 #.@.==...#
3 #...~~...#
4 ####~~...#
5 #...~~...#
6 #.@.==...#
7 #...~~...#
8 #.##~~####
9 #...~~...#
10 #...==.@.#
11 #...~~...#
12 ####~~####

MAP001 (top layer):
A single # tile at 1, 8.
Because the attributes of the top layer do not matter, 1, 8 will look like a wall, but it is a secret passage.

Next, everything else that needs to be stored with the map to make it work:

Code:

Messages:
MES_MAP001_WARP "Teleport!"
MES_MAP001_BROKEN "Seems to be broken."

Locations:
LOC_MAP001_TOP MAP001, 2, 2
LOC_MAP001_MIDDLE MAP001, 2, 6
LOC_MAP001_BOTTOM MAP001, 8, 10

Events:
EVT_MAP001_00 @ LOC_MAP001_TOP
MESSAGE MES_MAP001_WARP
MAPJUMP LOC_MAP001_BOTTOM
EVT_MAP001_01 @ LOC_MAP001_BOTTOM
MESSAGE MES_MAP001_WARP
MAPJUMP LOC_MAP001_TOP
EVT_MAP001_01 @ LOC_MAP001_MIDDLE
MESSAGE MES_MAP001_WARP
MESSAGE MES_MAP001_BROKEN

All of this is on the level of pseudo code, but I guess my challenge to you is add random battles and a couple more maps to this and turn it into a simple demo. If I were to do this I would a have onUpdate() and onMove() scripts attached to each map, and onEnter() scripts attached to individial tiles.

I'd also have an onSearch() script for events and a canEnter flag for events. This way, an NPC is just an event with a canEnter flag set to false and an onSearch() script that displays a message. If you go this route, events will also probably want onUpdate() events, and they will need to be able to move and display themselves (although many events will be invisible).

There are lots and lots of scripts involved in an RPG. Every one of the critters that runs in your battle engine will need AI scripts. The FFV advance algorithm FAQ covers how that game handled monster AI.

Ah yeah, the onFoo() scripting.. I used to that with Sphere.
My plan for the map collision, etc is to have 2 layers, and the player can be on layer 0 or layer 1 (i.e. Baron Castle to the right), and that all tiles are referenced to a table with "status" data (like forest, water, land, wall, etc) so it's more flexible.

What I plan to do with the maps and onEnter() scripts, is set up events (warp points and what not.. can't believe my friend lost the last demo I sent him with full map collision, events, etc -.-'), chests, entities that only need appear at a specific point, etc.
_________________
I'm 18 and have Asperger's, so if I don't get something at first, just bear with me. *nod*

That is an interesting use of layers. I'd probably reserve another (hardware) BG for effects (fog, paralax BGs, etc) and one for menus / text.

It doesn't matter what you call it, but events, chests, and entities should be the same different versions of the same thing.

Code:

// Chest; you would probably simplify put all this in a searchChest(pChestId) routine
onSearch()
{
chestId = CHEST023;
if ( getFlag(chestId) ) // true = opened
{
   message( MES_GLOBAL_CHEST_EMPTY );
}
else
{
   setFlag( chestId );
   addItem( getChestItem(chestId) );
   // presumably message() can figure out
   // what the item name is using engine variables and message tags
   message( MES_GLOBAL_CHEST_GET_ITEM );
}
}

// Event
onEnter()
{
fullHealParty();
message(MES_WARP_TO_ABC_CASTLE);
mapJump(LOC_ABC_CASTLE);
}

// NPC
onSearch()
{
message(MES_WELCOME_TO_ABC_CASTLE);
}

Having said that, the hard part is actually finishing a demo.

What I had planned for events/warps/etc was using something that someone suggested here once.. I think it was tepples but I can't be sure.

Code:

//In stdfx.h . . .
#define EvActive 0x01
#define EvOnCond 0x02
#define EvAlways 0x04

typedef struct __Event_t {
u16 stat, x, y, layer;
void *Func;
void *Cond;
} Event_t;

//In Event.c . . .
static InSBSS Event_t EvTable[32];

//Adds an event
void EventAdd(Event_t *Event) {
static EvCnt = 0;

if(!Event) return;
if(EvCnt >= 32) return;

EvTable[EvCnt++] = *Event;
}

//Clears the list
void EventClearAll(void) {
int i = 31;
do {
EvTable[i].stat = 0;
} while(i-- > 0);
}

//Handles events
void EventHandle(void) {
static int NeedRefresh = 1;

if(!NeedRefresh)
return;
NeedRefresh = 0;

int i = 31;
do {
Event_t *Ev = EvTable[i];

if((Ev->Stat & EvActive) == 0)
continue;

//Psuedo-code for a bit. :P
if(
(Player->x != Ev->X || Player->y != Ev->Y) &&
(Ev->Stat & EvAlways) == 0
) continue;

if(Ev->Stat & EvOnCond) {
int (*Func)(void) = Ev->Cond;
if(!Func())
continue;
}

void (*Func)(void) = Ev->Func;
Func();
} while(i-- > 0);
}

Setting those up is handled upon map enter (onEnter) and yeah.

The event code you posted should get the job done for warps and invisible events.
I suppose it might even be able to handle NPCs, chests and other visible events depending on how you do things.

RPG Maker is actually a blueprint of everything you will need in an RPG.
If you have not done so already, download it and play around with it for a bit.
In your demo or complete RPG, you will essentially need to take every feature in RPG Maker and either clone it, customize it (improve, simplify, etc), or leave it out.

Because the challenge right now is finishing the demo at all, and not making the best game ever, you should focus on what to simplify or leave out.
I would decide on a minimum feature set, and then make a throwaway prototype, and then do everything to finish that throwaway prototype ASAP (including hard coding things and giving up flexibility).
After you have a working prototype, you can either refactor it or build a proper engine from the ground up after looking at the weaknesses in the prototype.
I'd opt for the second option after deciding on final feature set.

Ok, I had to put sprites/entities on hold for now, since I just found a minor issue with big maps...

In short, I can do big maps fine when they're 256x256, but they become funny when doing anything else. By funny, I mean that the baseblock thing is driving me bananas. It should be sorted out by the end of the night so...

Yeah, I've used RPG Maker in the past.. RPG Maker, Game Maker, Sphere, you name it.

The cool thing about Sphere, is that you had to write the battle engine yourself and other nifty little things.

What I wanted to do for chests and stuff is make them NPC's whose "OnQueueEmpty" script is 0 (or, do nothing) and have them modified on map entry if needed.

Now back to Tonc and my code.. -.-'

Ruben wrote:

In short, I can do big maps fine when they're 256x256, but they become funny when doing anything else.

This strikes me as a matter of lesser importance because it doesn't prevent you from completing a demo. I'd document it and fix it later.

I'd probably give events a userData field. This way you can use the same scripts for similar behavior. Ie, give the chest script a contents id, or a message script the message id, etc.

Quote:

This strikes me as a matter of lesser importance because it doesn't prevent you from completing a demo

Well, if you wanted world map, then it does prevent me. :P

When in mode 7 (for airships), you'll need a map bigger then 256x256 (namely 512x256) so you don't see retardedness on the sides.

Though coming to think of it, it doesn't.. it just doesn't let me try airships ;)

Ruben wrote:

When in mode 7 (for airships), you'll need a map bigger then 256x256 (namely 512x256) so you don't see retardedness on the sides.

Again, this is a demo. We know that if you can pull off a complete demo you'll be able to fix minor things like the size of the map. The demo does not need to be perfect, just complete.

Heh, yeah.. I realized that a bit later. :P

Anyway.. it's 2am, so I'm gonna keep coding the music player (I don't feel like working my head too much :P) for the game and go to sleep.

PM'ed link link to site containing technical information on FFIV.
The algorithm FAQs on gamefaqs are also recommended reading.

Got it. Thanks. :)

Alright, I'll admit it: I've been a lazya** lately.
So... starting today, I'm going to actually start implementing maps (again), as I deleted the old demo on purpose and forced myself to re-write everything, in doing so making things MUCH better and organized. So far, I've got working my Midi player/converter, message boxes, special effects, etc. (And yeah, in the Midi converter, it handles track looping: It uses a Data Entry MSB value of 127 for loop start and 126 for loop end, as this is one of the rare commands that I can use in NoteWorthy Composer) so hopefully, by the end of the day, I'll have the "map" structure and a test map setup using Mappy.

Bleh, sorry about the huge 'break'.. I've been busy with school and then I've been making more music than needed >>'

So anyway.. About 10 minutes ago, I finished coding the map and sprite interaction thing (that is, non-players move locally, while player moves globally (that is, scrolling camera)), and the only thing left before I release the first demo is to add these things:

-Collision [Completed as of 06/08 (MM/DD) @ ~8am]
-Interaction with other entities [Completed as of 06/09 (MM/DD) @ ~1am]
-Another map [ended up using same map, warping to random locations]

When that's done, I'll release a demo. :)

--

And since that's done, I'll upload it.. *uploads*
Ok, done. You can get it here

Last edited by Ruben on Mon Jun 08, 2009 8:43 pm; edited 3 times in total

We'll look forward to seeing it.

Now that that's done, the next thing on the list is to add events. Shouldn't be too hard, but vital. After that.. hm, I'm not sure, lol! Maybe more music ><'

At what milestone do you release your demo?

What's milestone? :-S

Ruben wrote:

Code:

//In Event.c . . .
static InSBSS Event_t EvTable[32];

//Adds an event
void EventAdd(Event_t *Event) {
static EvCnt = 0;

if(!Event) return;
if(EvCnt >= 32) return;

EvTable[EvCnt++] = *Event;
}

hum, just a quick C question unrelated to the whole thread... sorry for hijacking...

with your "static EvCnt = 0;" when is the initializer executed? it look obvious it is not initialized at every call or your code would be bogus, but i'dd just like to be sure. Never used static variable with an initializer yet but i am not too old to learn...

The static keyword makes the variable relative only to the current file. Don't really have to make it static but it's still good IMO for that case so I don't rename another global the same name.

thanks, but the question was not about the static, but about the initializer... visibly it's not called everytime you call that method, the question is: is it called at all?

well "static EvCnt = 0;" will give you a compiler error. I imagine that "static int EvCnt = 0;" was the intent.

static on a local variable essentialy changes it to a global variable that is available to the current function only. it gets initialized in the same manner as global variables - space is reserved by the compiler and constructors (if applicable) are called by the c runtime sometime before main is entered. I think it can get a little tricky with constructors as the order is compiler dependent.

in this case space would be reserved in the bss section and the c runtime zeros the bss section before main is called.

static on global variables and functions allows the compiler to optimize more aggressively.

static on local variables is usefull for allowing global variables that do not pollute the global namespace.

elhobbs wrote:

well "static EvCnt = 0;" will give you a compiler error. I imagine that "static int EvCnt = 0;" was the intent.

No. In C, int is implicit, so "static EvCnt = 0;" has the identical meaning to "static int EvCnt = 0;"

kusma wrote:

elhobbs wrote:

well "static EvCnt = 0;" will give you a compiler error. I imagine that "static int EvCnt = 0;" was the intent.

No. In C, int is implicit, so "static EvCnt = 0;" has the identical meaning to "static int EvCnt = 0;"

yep, that's right, some (most?) compiler (visual studio one at least) report warning trough...
thanks for clearing everything up, it was exactly as I was thinking, but I wasn't sure at all to be right...

Ruben wrote:

What's milestone? :-S

A certain goal or point in a timeline or schedule. Another way to say this would be: at what point of development will you release a demo?

elwing wrote:

some (most?) compiler (visual studio one at least) report warning trough...

Neither Visual Studio 2008 nor GCC 4.4.0 warns on this code (with default settings):

Code:

int test() { static i = 0; return i++; }

kusma wrote:

elhobbs wrote:

well "static EvCnt = 0;" will give you a compiler error. I imagine that "static int EvCnt = 0;" was the intent.

No. In C, int is implicit, so "static EvCnt = 0;" has the identical meaning to "static int EvCnt = 0;"

wow, what a useless/confusing feature. I had never seen that before. my apologies.

elhobbs wrote:

wow, what a useless/confusing feature. I had never seen that before. my apologies.

It's there for backward-compatibility. The first versions of C were typeless IIRC; everything were integers. Kinda made sense when coming from ASM (at least before FPUs etc).

OK, enough thread-hijacking ;)

Meep, sorry, went to sleep at ~5pm and just woke up (~8:31am) xD

Well, I'd say I'm currently at like.. 10% of the demo.. when the battle engine is done and I've added events it will be like ... 15%, then when I start adding more "real" maps rather than test ones, I'd say ~20%.

(And yeah, the intent was "static int" but at least you got the idea. :P)

Alrighty, I've re-written the entity handling code, the event handling code, the music player, map handler, etc... and I've even added the rotation about the center of the screen for boarding the airship :D

I'll just whip up a map or two and then I'll release the newest demo, which handles sprites properly and doesn't screw up (as much anyway.. there's a small bug that I have to figure out that makes the screen flash after "landing" the airship).

Also, I've changed the colouring for messages to a soft blue and re-wrote the scope on the music player. (It sucks being sick.. I didn't get to do as much as I wanted :-/)

Alright, latest demo available here: http://www.filefactory.com/file/ag79g59/n/FFIV-2_EngineDemo_zip

Now onto the horror of the battle engine ;)

Comments on your demo:

Questions about your demo:

Ruben wrote:

Now onto the horror of the battle engine ;)

Seems to me that an RPG battle engine ought to be easier than the field engine as long as you stay low spec.

Quote:

Overall, it looks really good.

Thanks :D

Quote:

You have a lunatic mode, but the description for deathwish mode is "for lunatic gamers".

Oops xD

Quote:

You should run a soft reset routine instead of terminating the program.

Hm, ok.

Quote:

As a black box observer, your scripting appears to be impressive -- SNIP --

Well, the scripting simply calls a C function pointer that can do anything that any function can do (heck, I can even reset the game during a script)

Quote:

Both of your test map NPCs delete themselves. It seems like there should be a couple persistent NPCs with simple messages ("Hi.") one that walks around and another that stands still.

Will do!

Quote:

Your demo is still lacking map jumps. If you create a couple of small towns or whatnot that the PC can enter and exit, I think that will add a lot to your demo.

Sure, that shouldn't be too hard... I just need to get out of bed and start working on them.

Now to answer your questions...

Quote:

Why the GBA and not the DS?

Because, quite honestly, the DS is simply horrible to me.. not in terms of specs, but rather programming for it. And the whole thing where the program must be copied to RAM drives me nuts, since I've never done on-the-fly resource handling (other than the mapping for the game engine, but that's a different story ;))

Quote:

Why the Square Enix splash screen?

Dunno.. maybe cos some of the graphics are from them? Idk, lol xD

Quote:

Are the scripts and messages hard coded (C/C++), or are your game events linked to script and message resources?

Um, not really sure what you mean by this.. But the events are coded in C, with messages calling the "PrintMessage" functions. It can do frame waits (with \x02 ~ \x08) and can clear the space it writes to with \x01.

Quote:

Are you always running your camera using the "mode 7" camera system or are you switching between two camera modes?

Currently, only the mode7 test runs the camera in mode 7, and the "Generic Map Test" runs in mode 0. However, I have yet to think up how to draw the dynamic maps for mode 7.

Quote:

Any plans for a source release?

Well, I'd release the source whenever, just don't know when to do so >>'

Quote:

Seems to me that an RPG battle engine ought to be easier than the field engine as long as you stay low spec.

True, true...

EDIT:

Oh yeah, and I just downloaded VS2008 (trial, but meh >>') to attempt to make a map editor. Windows Forms, here I come! >>'

Ruben wrote:

Quote:

You should run a soft reset routine instead of terminating the program.

Hm, ok.

Turning the system off and on is a bother.

Ruben wrote:

Well, the scripting simply calls a C function pointer that can do anything that any function can do (heck, I can even reset the game during a script)

Using a sandboxed scripting language is ideal. Scripts written in C have the potential to do horrible horrible things. Also, writing scripts is presumably easier than writing C code, so scripting should make it easier to grow your team. To the extent you have the C side of the scripts written already, binding a scripting language to them should be fairly simple.

Ruben wrote:

Quote:

Your demo is still lacking map jumps. If you create a couple of small towns or whatnot that the PC can enter and exit, I think that will add a lot to your demo.

Sure, that shouldn't be too hard... I just need to get out of bed and start working on them.

With support for multiple maps and a battle engine, you should be able to make a demo mini-quest.

Ruben wrote:

Because, quite honestly, the DS is simply horrible to me..

In theory you should be able to port this to the DS later if you want to.

Ruben wrote:

not in terms of specs, but rather programming for it. And the whole thing where the program must be copied to RAM drives me nuts, since I've never done on-the-fly resource handling (other than the mapping for the game engine, but that's a different story ;))

A full scale RPG is going to have hunderds of maps, with a bunch of scripts and messages for each map, as well as global scripts and messages. Given everything that needs to go into an RPG, I think taking advantage of the SD card's drag and drop filesystem would simplify development, especially if there are multiple people working on the project.

Ruben wrote:

Currently, only the mode7 test runs the camera in mode 7, and the "Generic Map Test" runs in mode 0. However, I have yet to think up how to draw the dynamic maps for mode 7.

Scrolling a mode 7 map is just like scrolling a mode 0 map, but you need to work out some math to get it to work. You might want to consider always running in the mode 7 camera mode, although IIRC you might not have enough background layers.

I noticed that your mode 7 test does not play music. It also does not display any diagnostic information. When you use the tilt screen, I noticed that some internal values are destructively overwritten.

Ruben wrote:

Quote:

Any plans for a source release?

Well, I'd release the source whenever, just don't know when to do so >>'

My thoughts on source code at this point are, just release it with each demo. A lot of people like to wait until they clean up the code, but it often does not get cleaned up and the source is never released. If people can glance over your code, they might spot potential bugs or architectural weaknesses for you.

Ruben wrote:

Oh yeah, and I just downloaded VS2008 (trial, but meh >>') to attempt to make a map editor. Windows Forms, here I come! >>'

I think it would be cool to have a DS map editor that uses the touch screen and saves to the SD card. =P (If only there were 72 hours in a day...) Having said that, there are plenty of reasons to make a PC map editor.

Quote:

Using a sandboxed scripting language is ideal.

Hm, true... But what I was thinking, was adding the events editor into the map editor, and you can have RPG Maker-ish commands to insert and then, when outputting the map, you'll get the C code for it.

Quote:

With support for multiple maps and a battle engine, you should be able to make a demo mini-quest.

Heh, yeah, I guess. :P

Quote:

A full scale RPG is going to have hunderds of maps, -- SNIP -- SD card's drag and drop filesystem would simplify development, especially if there are multiple people working on the project.

*EPIC CRINGE!!!!* I never like the whole idea of filesystems.. :P
Maybe once people take a look at it, they may be able to figure it out (and hopefully keep me out of it >>')

Quote:

Scrolling a mode 7 map is just like scrolling a mode 0 map, but you need to work out some math to get it to work. You might want to consider always running in the mode 7 camera mode, although IIRC you might not have enough background layers.

Hm, true.. I actually have enough layers, the problem is the tiles: the usual map will use > 255 tiles which would render mode 7 useless.

Quote:

I noticed that your mode 7 test does not play music. It also does not display any diagnostic information. When you use the tilt screen, I noticed that some internal values are destructively overwritten.

It doesn't play music cos I still haven't finished the "Airship" song. :P
No diagnostic information cos.. well.. I guess I just didn't bother, yet :P
And yeah, some values are destructed until I can find out how to rotate even after changing yaw or whatever.

Quote:

My thoughts on source code at this point are, just release it with each demo.

Hm, ok. In the next release on, I'll start releasing the source (but skipping the sound .s files for obvious reasons :P).

Quote:

*EPIC CRINGE!!!!* I never like the whole idea of filesystems.. :P

A filesystem seems like the easiest way to manage everything. Have you done much programming on the PC using files? Files are not hard to use...

Quote:

Maybe once people take a look at it, they may be able to figure it out (and hopefully keep me out of it >>')

If you give it a couple of days, you ought to be able to figure it out, but you are free to insist on not giving it a shot.

An RPG typically has a tremendous number of messages and scripts that need to be organized. Some of them are global and need to be used all over the place (chest, inn), and others are local to specific maps:

Code:

Global
message-global
   message-global-000
   message-global-001
   ...
   message-global-FFF
script-global
   script-global-000
   script-global-001
   ...
   script-global-FFF
Map-000
message-000
   message-000-000
   ...
   message-000-FFF
script-000
   script-000-000
   ...
   script-000-FFF
Map-001
...
...

Map-FFF
...

Most maps will only use a few messages and scripts.

Ruben wrote:

Hm, true... But what I was thinking, was adding the events editor into the map editor, and you can have RPG Maker-ish commands to insert and then, when outputting the map, you'll get the C code for it.

You are free to do this, but personally, I absolutely hate the push button scripting RPG Maker uses. It is very useful if you can open the scripts in any text editor (some have fancy features) or pass them through perl scripts, etc. If the event scripts are edited after exporting, the editor should be able to pick up on these chages.

As far as NPCs go, I'd give them two values, a script ID and a data parameter for the script. This way, you only need to create one inn script, one chest script, one local message script and you can change the exact behavior with the data parameter. (This inn costs 120 gold; this is chest 77, so used flag 77 and chest contents 77; this event prints the MES_HELLO_WORLD message.) I think you will find that you have a few global scripts that get used more than anything else.

As far as messages go, inline text is a Bad Thing when it comes to localization and it also make reuse difficult.

Code:

PrintMessage("All your base are belong to us."); // inline text - bad
PrintMessage(MES_ALL_YOUR_BASE); // tagged message - good

Quote:

With support for multiple maps and a battle engine, you should be able to make a demo mini-quest.

Heh, yeah, I guess. :P

A demo mini-quest ought to be enough to get more people to pay attention to your project, so long as it is extensible.

Quote:

You might want to consider always running in the mode 7 camera mode, although IIRC you might not have enough background layers.

Hm, true.. I actually have enough layers, the problem is the tiles: the usual map will use > 255 tiles which would render mode 7 useless.[/quote]
Does an FFIV spec RPG actually use more than 255 tiles per map?

Quote:

It doesn't play music cos I still haven't finished the "Airship" song. :P

Why not use the Redwings song just to make sure that you have enough cycles for both music and the camera as implemented?

Quote:

No diagnostic information cos.. well.. I guess I just didn't bother, yet :P

Sure, if you have time.

Quote:

And yeah, some values are destructed until I can find out how to rotate even after changing yaw or whatever.

More math.

Quote:

A filesystem seems like the easiest way to manage everything. Have you done much programming on the PC using files? Files are not hard to use...

Yeah, I've had to use them for my Midi and Aiff converter, but.. D:
The idea of having multiple files in a folder for a game simply scares me... Maybe I'll think of implementing something like gbfs or something if needed.

Quote:

Most maps will only use a few messages and scripts.

Yeah, that is true.. I suppose I could have a function pointer for the required inn person, and just call PrintMessage(GLOBAL_MESSAGE_BODY, 72); (my Print function can print numbers, lol :P).. or I could do what you said and simply pass a-- .. hold on... how about a global script for inns, and having the gil amount in the map header (that is, the actual data header, not the .h file)?

Quote:

You are free to do this, but personally, I absolutely hate the push button scripting RPG Maker uses.

Hm, I guess I never really thought about that.. maybe I'll have to get people's opinions later on?

Quote:

As far as messages go, inline text is a Bad Thing when it comes to localization and it also make reuse difficult.

I suppose that's rather simple to implement... I can make a function called PrintByIdx(int Index) and print the right message with locality stuffs.

Quote:

Does an FFIV spec RPG actually use more than 255 tiles per map?

Unfortunately, yeah. The only time it uses 255 tiles is for the world map.

Quote:

Why not use the Redwings song just to make sure that you have enough cycles for both music and the camera as implemented?

Cos I just bothered writing "The Airship" :P
And yeah, it times out fine (now anyway :P).. had to place the H-Blank routine in IWRAM cos it was screwing up after changing around the order of things.

Quote:

Sure, if you have time.

Alright *adds that when I'm done*

Quote:

More math.

Gah! xD
It was bad enough realizing that the anti-clockwise x/y rotation matrix wasn't what I needed and then re-organizing :P

All I do with it right now is, on suggestion from DekuTree, I have a vector which I'll name P, which is simply (0.0,Cy,0.0), where C is the camera position vector. What I do during the "moving" loop, is simply rotate P to get P', and then use Py' for Cy' and Cz' is calculated using Pz'+Cz.

And since my 3D math sucks, I'll bet that doesn't make sense. :P

---

Oh and also, I added an "AgbTrace" function that sends AgbPrint messages to VBA (added it when trying to find out the rotation error). It's not very optimized but it gets the job done.

Ruben wrote:

Quote:

A filesystem *snip*

Yeah, I've had to use them for my Midi and Aiff converter, but.. D:
The idea of having multiple files in a folder for a game simply scares me... Maybe I'll think of implementing something like gbfs or something if needed.

You only need a few custom file handling routines, and after they are written you just call them and everything magically works. (If they still have bugs, everything has not been worked out yet. =)

Another advantage to a filesystem is that you can test changes without an engine recompile. You just drop your new map in and see how it works. As an army of one this is not a big deal, but if you are working with other people it is nifty to give them the most up to date version of the engine and let them work on and test the content.

Ruben wrote:

Quote:

Most maps will only use a few messages and scripts.

Yeah, that is true.. I suppose I could have a function pointer for the required inn person, and just call PrintMessage(GLOBAL_MESSAGE_BODY, 72); (my Print function can print numbers, lol :P)..

The inn script is going to do more than just print a message.

Code:

void event_g_inn(int pCost)
{
PrintMessage(MESS_G_INN_WELCOME, pCost);
if (ChoiceYesNo())
{
if (PlayerMoney() < pCost)
{
PrintMessage(MESS_G_NO_MONEY);
}
else
{
PlayerMoneyChange(-pCost);
FadeOut();
PlaySE(SE_INN_STAY);
FullHeal();
FadeIn();
}
}
PrintMessage(MESS_G_INN_THANK_YOU);
}

A chest script is even more interesting:

Code:

void event_g_chest(int pChestId)
{
int opened;
int item = ITEM_NONE;
int gold = 0;

if (IsChestOpened(pChestId))
{
PrintMessage(MESS_G_CHEST_EMPTY);
}
else
{
int item = ChestItem(pChestId);
int gold = ChestGold(pChestId);

ChestOpen(pChestId);
if (ChestGold(pChestId))
{
PrintMessage(MESS_G_CHEST_GOLD, gold);
}
else
{
PrintMessage(MESS_G_CHEST_ITEM, ItemString(item));
}
}
}

An integer can be used to look things up. In the case of a chest, whether it has been opened or not and the contents.

By attaching functionality and and a piece of data to your NPCs, you only need to write each generic event only once and the exact funtionality can be changed simply by replacing the data field. The function pointer (or index into an array of function pointers) answers the question "What is this NPC in a generic sense?" (an inn keeper; a chest). If you attach data as well, that answers the question "Specifically, what is this NPC?" (the guy who charges 120GP; chest 77 (unopened, cointains an ether)).

Quote:

or I could do what you said and simply pass a-- .. hold on... how about a global script for inns, and having the gil amount in the map header (that is, the actual data header, not the .h file)?

There are many ways to get the job done. One nice thing about having a clearly defined spec is that it is easy to tell if you have enough flexibility built into your architecture. My thoughts are, why attach an inn cost to every map when only a handful of them will actually have an inn? What if you want two inn keepers on the same map? What if you want an inn that charges a random amount?

Code:

void event_g_inn_random(int pCost)
{
event_g_inn(pCost + Random(pCost) - Random(pCost));
}

Quote:

I suppose that's rather simple to implement... I can make a function called PrintByIdx(int Index) and print the right message with locality stuffs.

None of this is hard stuff. In case you have not noticed, embedded string functions are very useful:

Code:

MES_FIND_ITEM
"You found #wait(10).#wait(10).#wait(10).#wait(10) #red()#an_item($0)#normal()!"

A text display system that combines embedded functions, precompiled text, and message parameters will be able to do everything you want it to.

Code:

void DisplayMessage(int pId, int pParamCount, int *pParamValue);

// collected from a script and passed to the text display system
int param[] = [ITEM_POTION];
int count = sizeof(param) / sizeof(int);
DisplayMessage(MES_FIND_ITEM, count, param);

I'm not sure if you need a text display system that is this powerful. It would require precompiled messages, although a regex filter in perl could probably handle the conversion.

Quote:

Does an FFIV spec RPG actually use more than 255 tiles per map?

Unfortunately, yeah. The only time it uses 255 tiles is for the world map.

Your choices are, change the spec or use two camera modes.

Quote:

More math.

Gah! xD
*snip
And since my 3D math sucks, I'll bet that doesn't make sense. :P

I wish I could help you, but I'm the wrong person to ask about 3D math. =)
Your mode 7 demo is much nicer than the broken one I never completed.

Quote:

Your choices are, change the spec or use two camera modes.

Hehe, way ahead of you :P
The map header contains flags which signal 8bpp tiles, wrapping (if wrapping is off, you get a single tile outside the border as can be seen in the demo), and affine/mode 7, which is handled upon calling "MapWarp(x,y,layer)"

Mini-game underway: You have to travel across an ice-ish cave, fighting random battles along the way, and then confront Shiva. After confronting her, she will agree to boost your coolness but just as she's going to, she falls back into the endless pit. :P

But now, since it's 1am, I'm going to sleep so I don't become an insomniac for the 5th millionth time >>'

Okay, maps and events are complete, I just need to add the battle engine :D

(Changed mini storyline to: Shiva is defeated and when she goes to give them coolness runs away out the back door, which you follow and the screen fades to white, then black and then the experiments window)

So you have a mini quest with no battles?

The mini quest involves random battles and a battle with Shiva :P
Maybe I just didn't make it obvious *shrug*

Unless you mean what I have right now, in which case that statement is correct (where did I pick up *THAT* language? :-S)

Ruben: That sleep-thing is kinda over-rated, huh? ;)

Ah-huh! Sure is >>'
(Damn.. getting late again ><')

a bit oftopic, but there is an officiel FF IV sequal on wiiware.

I know. :P
It's called FFIV - The After Years.
I just wanted to make a sequel with another story, is all.

I think the first version of your battle engine should support the following features and very few, if any, other features:

vuurrobin wrote:

a bit oftopic, but there is an officiel FF IV sequal on wiiware.

Is this the one that came out on the cell phones in Japan? How much is it?

Ok, I'm going to be going to do a TAFE course in Victoria University, so I may not be around for a while... Therefore, I'm going to upload the latest copy of my game. However, I'll admit that I haven't done as much work on it as I would've wanted: I've been sick and busy doing other stuff.

That aside, the battle engine seems to be working fine, except for the fact that I haven't written code to display the character data: This shouldn't be difficult at all, but I don't really have much time; hopefully I will after my courses.

Ok, that's the end of my rant. :P *uploads file*
I've included all of the sources, minus the sound and music .s files and the Midi converter source, but that's a different story ;)

I've included my latest "Mid2XMid" program, however I haven't added an "Aif2XMid" program for a reason that becomes obvious once you open the MakeSounds.bat file: it uses the official Aif2Agb program, which is why I'm busy trying to make an Aif2XMid program: I can't stand the illegality of it, but the AIFF format is driving me nuts, so for now I'm using that, as I'll need the loop points pre-set: hopefully I'll find the reason for those empty gaps every now and then that I can't explain >>'
I also may be able to speed up the mixer if I use unsigned samples, too, but until I get the conversion program working that will have to wait ><'

Anyway, the file is ZIP'ed and is 6.02MB in size. You can get it here.
_________________
I'm 18 and have Asperger's, so if I don't get something at first, just bear with me. *nod*

Alright, after coming back from Sydney (yes, I was there for my mum's religious stuffs) and having a lot of time to myself and being able to reflect upon what I want (aka, I didn't bring the charger for my laptop T_T')......

I am thinking of making the engine over again from scratch, but this time for the DS.

I was wondering what your opinion would be on this: Would you like it to be on the DS, or another platform? 3D or 2D? Midi or tracker?
_________________
I'm 18 and have Asperger's, so if I don't get something at first, just bear with me. *nod*

don't worry about what people want. work on what interests you. I say finish what you started as that is the most difficult thing to do. if you never finish anything than it does not really matter what you start.

Ruben wrote:

I am thinking of making the engine over again from scratch, but this time for the DS.

I was wondering what your opinion would be on this: Would you like it to be on the DS, or another platform? 3D or 2D? Midi or tracker?

If your engine supports drag and drop assets, the DS makes a lot of sense. To the extent you have written the engine once, you should be able to do a better job the next time around. (The GBA version would be your throw away prototype.) I like 2D RPGs. Not fussy about music, but I suppose "both" midi and tracker would be the friendliest.

If I were you, I'd spend a week and tie Lua to your GBA engine before doing the DS one from scratch, but if you have no interest in that, skip it.

---
The scripting issue
---

Well, from what I had been thinking over at Sydney, I thought up an assembly file driven scripting thingo.. um, kinda hard to explain so I'll write an example...

Code:

1:
.byte COM_IF
.byte VAR_BATWIN, SCV_EQ, VAL_BATWIN
.byte GOTO
.word 1f
@ Do some other stuff here
.byte GOTO
.word 1b

@ Battle won
1:

COM is for "Communication" or "Command", SCV is for "Scripting Conditional Value", VAL is for "Value" and BATWIN is for "Battle Win".

Basically what it does is, if the battle has been won, then it jumps to 1f, otherwise it does some other stuff then jumps back to 1b.

---
The sound issue
---

So both Midi and tracker? Hm, I suppose that's doable... Just have to get started on the new DS code and converter for the tracker format, and possibly optimize for both Midi and tracker to use the same structure.

---
The video issue
---

Hm, so 2D over 3D? For now I guess it stands at that, but since it's only 1 person's opinion I'll just do "generic" stuff like menus, text blitting, etc.
_________________
I'm 18 and have Asperger's, so if I don't get something at first, just bear with me. *nod*

If you're keeping it in 2d, the DS is so similar to the GBA that you shouldn't have to rewrite very much.

Ruben wrote:

---
The scripting issue
---

Well, from what I had been thinking over at Sydney, I thought up an assembly file driven scripting thingo..

This is the kind of stuff Square used in the 90s. The person writing ASM style scripts can keep track of what is going on, but they are really hard for anyone else to understand, let alone edit.

Development ease/speed are just as, if not more, important than execution speed. Nobody should be coding scripts in an ASM-like language anymore. If you have the time and energy to write a compiler for your VM and you want to do that, go for it. Personally I would stick with something like Lua for development ease, speed and portability.

Ruben wrote:

---
The sound issue
---

So both Midi and tracker? Hm, I suppose that's doable... Just have to get started on the new DS code and converter for the tracker format, and possibly optimize for both Midi and tracker to use the same structure.

I can't tell you if it is worth your time to support both. There are only 24 hours in a day and only you know what your priorities are.

Ruben wrote:

---
The video issue
---

Hm, so 2D over 3D? For now I guess it stands at that, but since it's only 1 person's opinion I'll just do "generic" stuff like menus, text blitting, etc.

*I* prefer 2D. It seems like original 2D assets ought to be cheaper than 3D assets, although these days I suspect more 3D modelers are being trained than pixel artists.

For DS, you can use either. 2D graphics can pretty easily be textured onto polys and then you get the 3D system's power (or said better, get around the 2D system's limitations.)

Scripting:
I personally don't care much for scripting systems. I would write events in C unless a) I needed to crunch for cart space, or b) I wanted someone else to write my events and they liked some other language.

Whatever the case, my general criteria for these things is "least total time". There's time to write the system, time to write events, and time to go back and edit/debug events. The edit/debug time is the most variable, depending on the skill of the scripter and how thoroughly planned out the game's story is before you start building maps and events.

Music:
Whatever you prefer to write in. I write more easily in MIDI, but my MIDI editor doesn't have an easy way to do pitch/volume slides, which I want, so I'm using tracker for my game. On GBA, I would also use tracker for the finer control over channel allocation.

DS/other system:
Actually I love the GBA, and have been wanting to make another game for it. But the second screen is kind of nice so you can keep walking around while you mess with equipment in the menu :)
Plus the GBA's sound is crap.

If not GBA or DS, then I'd suggest cross-platform with OpenGL/SDL for graphics and stuff. The GP2X community is pretty cool, and they have a new system call Wiz, and upcoming system called Pandora, which don't need so much special care like GBA/DS. And then you could also release for PC to get a lot more players.

2D/3D:
2D. 3D doesn't make it exponentially harder, but just the basic time to get an engine set up and all the exporters and map editor and stuff to actually create data is just too big to bother with. Especially because I think 2D looks better in the end.

But using the DS's 3D hardware to display 2D graphics is a definite option. Just keep in mind that there's a second screen that doesn't have 3D hardware, so you'll have to write some things for both anyway.
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku

Ok, so after much inactivity (I was actually doing some other mini-projects but anyway..).. I decided to start the whole game from scratch again, but instead, this time make the necessary stuff as I need it, and I build the game itself.

Everything has been going very well so far, but I've currently hit a major brick wall: maps.

The only maps I can find for FFIV are maps that are either:
- Maps with animated tiles that were timed differently for each shot
- Maps that are off by a few pixels, which I can't really correct
- Both of the above

So seeing as this is stalling me ATM, I came here...

Does anyone have any idea what I should do?
_________________
I'm 18 and have Asperger's, so if I don't get something at first, just bear with me. *nod*

Why would a map that is inaccurate by a few pixels compeltely stall you?

Because it can end up using more tiles than actually usable, and because it mucks me up for animated tiles and stuff.
_________________
I'm 18 and have Asperger's, so if I don't get something at first, just bear with me. *nod*

I'll need more detail to give advice. Can you list a particular map by name and say exactly where the problem areas are? Animating tiles should not be all that hard and I don't understand the pixel problem at all.

Ok...

For this example, I'll say the world map.

As you know, the map is made up of "water" "terrain" "grassland" and "desert." Some tiles are joined up to the water tiles, which we know are animated to simulate the sea.

The problem here, is that all maps I've found have one or more 'sections' of the snapshot taken from a different animation frame, which bloats the tiles a bit. That wouldn't be much of a problem, as animated tiles would be modified on runtime anyway, but it does mean I have to copy to two different places because of a single mismatch.

The pixel problem is that, for example, a certain section of the map is accidentally offset by a few pixels, which 'destabilizes' the whole thing, as all tiles can be different, and it could be that they ripped the 'land' and pasted it over the water tiles, which would mean the water tiles would be fine, whilst the land tiles are offset a bit, which mucks up the tiles even further.
_________________
I'm 18 and have Asperger's, so if I don't get something at first, just bear with me. *nod*

Wouldn't you want to 'paint' your own map with a land index of some sort, then use that lookup map to display tiles? If you had a 99% accurate pixel map, I wouldn't think it would take too long to generate that base map and go from there.

I don't completely understand what Mike is suggesting, but...

I think what Ruben saying is that he wants to rip and use the actual maps from the original FF game. So he found images of the maps ripped online, and is trying to use (or write?) a tool to automatically convert that to be used in his game. But this automatic conversion falls apart because the source image isn't consistent.

It's not a simple problem to overcome. As far as I can tell, you have 3 options:

-You could write special exceptions into your import tool to handle all the inaccuracies
-You could go back and fix the source images by hand
-You recreate the maps yourself based on the originals.

None of those sound fun. If you wrote a special tool to do #3 (where it could display the source image behind the map as you're creating it), that may be slightly less work. I dunno.

Hm, what exactly do you mean, Mike?
If you mean ripping the 'tiles' and 'drawing' the map from there... that's... a bit too much work ;)
(It's 241x231 16x16 tiles)

gauauu:

Yes, I meant that I want to use the maps used from FFIV and the rest is correct, too.

Option 1: That does NOT sound fun >_>
Option 2: Yeah, I've been trying that, but it's EXTREMELY hard to find inaccuracies with a 55200 tile map >_>'
Option 3: That option has been looking like the best one, lately, but it would take a HELL of a lot of time, so I'm not sure it's worth it. However, seeing as how long I've been taking to do all this other stuff, it may seem like the way to go.

A tool that does something like this:

Read in a tile from your source image. Rank it versus all known tile types via RGB channel deltas. This can be done via horizontal and vertical scans to catch alignment innaccuracies in different direction. It should also phase/pixel shift the tiles to catch off by 1 or two or more pixel shift errors. Have it output the info in a usable format - say a text csv type file. Take the file and render it. And hand fix the few tiles it misses.

IIRC, even the maps in FFIV are at least a couple of layers. Working from screenshots, it will be hard to split the map into layers.

FFIV has been reverse engineered backwards and forwards. To the extent you don't want to make your own maps, I think the easy way to solve this problem is to dive into the RE documents and rip the data from the SNES version of the game.

Well, what I've started to do is write the map tile for tile. It'll take a while, but at least it will be 'correct'. And it's actually not as boring as I originally though. =)

Grr, well this is an news-only update I should've done LONG ago but..

- My desktop computer (the one that has all my data, programming, documents etc) is currently not working (and hasn't been for quite a while), as my PCIe port got damaged by a faulty video card, and have since been waiting for AGES to get a PCI video card. So until I can get a hold of a PCI video card, there's not much I can do. :-/

- My laptop had been damaged, too, and I only got around to fixing it today (even if the keyboard became faulty which makes me use a USB one >_>), so I wasn't as active as usual as we only have one other computer working.

- Said laptop has, quite literally, *no* programming resources at ALL, therefore I can not program until I can get on my desktop. (Even if I wanted to program, I can't as this computer is VERY slow even on WinXP so compiling takes too long for my own good)

- I will (hopefully) be more active on the forums now that my laptop is somewhat functional. However, as I've mentioned a few times, I can *not* program anything on here until I get a video card (which I ordered today; should be here in ~2 weeks).

So yeah. Sorry about this major 'episode' guys, but I seriously can not do anything with nothing. :-/

If you still want to work on your project, use this downtime to review the technical specs of the SNES version of the game. I suspect someone has figured out the maps, and it will be a lot easier to rip them than hand code. I bet you would make productivity gains on the first world map alone.

Ok, so... I finally got my new computer, so...

For the last 2 days, I've been ripping sprite graphics from FFIV advance; I've ripped most of the sprites using 80kb. What is interesting to note is that all that 80kb use only 3x 16 colour palettes.

Anyway, I've also finished the map engine and the sprite engine. What I'm doing right now is currently re-organizing all the sprites into a format I can use and then I'll be able to include them all into the maps' enter scripts. Also, I made a camKill() function that disables the camera and restores some blend values used for shading, and disables all sprites in camData.obj[].

So... I'm gonna keep working on that for now and upload a release ASAP.
Bad thing is that I don't have internet on that computer for another 2 weeks >_<'

Ok, update:

I still don't have internet on the other computer, so all I've done is be bored because the world map is WAY too big to be done all at once. I have done some minor programming, but it's still pretty alpha-stage.

Sources + binary: http://www.filefactory.com/file/a14h751/n/FFIV_DoD_rar

You can hold KEY_SELECT down just before it starts to enter a 'debug' mode where you can test the music (along with a cool volume effect) and the [two] maps.

Ruben wrote:

I still don't have internet on the other computer, so all I've done is be bored because the world map is WAY too big to be done all at once.

If you must use the original map, I still think you would see productivity gains if you ripped it. Evidently there are tools out there for customizing FFIV. I do not know exactly what they do, but I suspect all of this has been reverse engineered already. Why reinvent the wheel?

I'm 're-inventing the wheel' because I plan to do game programming as a career, so in case I need to do something similar to this while in uni, I'll know what it's like.

I think there's a program for the SNES version of FFIV that lets you edit the world maps. I could probably use that for ripping the map, but it's probably more understandable to write it from scratch?

There are very few cases where one needs to reverse engineer anything as a games programmer. Almost all of the time you are engineering new systems from pre-existing specifications.

Hand coding maps is data entry, not programming. If I needed a small amount of this work done, I'd use cheap non-programmer labor to do it. If I needed a lot of it done, a have someone program a conversion tool. Without knowledge of the original data format, I'd need a very good reason to bother fussing around with it at all.

My question for you is, what do you really want to get done? If your goal is to make a game, put as much of your time into getting the game up and running as you can. If your goal is to write tools, then write tools for your clearly defined specs. If your goal is to reverse engineer FFIV, then reverse FFIV. If your goal is really to hand code maps, then go for it, but it does not sound like it is.

I recommend that you look into the SNES tool you mentioned. See if it has source code. I don't recommend rewriting the tool unless it is trivial or missing a feature that can not easily be added. There will be plenty of other opportunities to practice and develop your mad skills.

Well, what I want to do is gain experience on game programming, gain experience on console programming (that is, platform-specific stuff), make an open-source RPG engine and also to release the game to everyone and have a prograsm ^-^'

What I've been doing since yesterday morning is writing my own functions (sound, FIFO, etc.) for the DS, as I now plan to start on the DS cos as I've noticed, it gets easier when one has a foundation one is comfortable with.

So far, I seem to have most things done (sound, FIFO, video, memory, ITCM/DTCM, etc.), and just need to tweak a few things. So aside from that, I have made ARM7/ARM9 stuff and joined them using ndstool. From what I've seen, it works just fine. So for now, I'm'a sleep. =P

I had a similar type experience of experience as you, and all I would say is beware of reinventing every wheel. It's a great to be versatile in your programming but at the same time it is very important to be able to reuse existing code rather than recreating all of it.

Look at what Google did with Chrome, they took lots of existing systems and created *in my opinion* the most powerful browser!

And as well as the low level stuff (which did allow me to achieve many things in my work that others could not have), it's important to develop your project management skills and games systems as well.

It's all fine being able to do everyone's job, but it's probably equally good to be able to work with code that isn't "to your standard". Communication is the word!

Other useful skills are teamwork and the ability to improve existing projects.

One of the main goals with devkitPro was accessibility to a wide range of skillsets. Recently the world and his dog seem to be trying to write their own frameworks from scratch and unleashing them on the poor defenceless homebrew community who are left not knowing which choices to make :/

Some days it feels like we're gradually moving back to the early GBA days when everyone had their own set of headers and patchset for gcc tools.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog

gbadev.org forum archive

Help Wanted > Looking for people to help with an FFIV sequel...

#168440 - Ruben - Wed Apr 29, 2009 12:20 pm

#168456 - gauauu - Wed Apr 29, 2009 3:09 pm

#168457 - Ruben - Wed Apr 29, 2009 3:12 pm

#168459 - sgeos - Wed Apr 29, 2009 4:19 pm

#168464 - Ruben - Wed Apr 29, 2009 4:53 pm

#168470 - gauauu - Wed Apr 29, 2009 7:41 pm

#168473 - sgeos - Wed Apr 29, 2009 11:19 pm

#168478 - Ruben - Thu Apr 30, 2009 4:13 am

#168480 - headspin - Thu Apr 30, 2009 4:16 am

#168481 - Ruben - Thu Apr 30, 2009 4:17 am

#168482 - headspin - Thu Apr 30, 2009 4:21 am

#168484 - Ruben - Thu Apr 30, 2009 7:38 am

#168485 - sgeos - Thu Apr 30, 2009 9:29 am

#168486 - Ruben - Thu Apr 30, 2009 9:38 am

#168487 - sgeos - Thu Apr 30, 2009 10:17 am

#168495 - Ruben - Fri May 01, 2009 5:42 am

#168498 - sgeos - Fri May 01, 2009 8:11 am

#168499 - Ruben - Fri May 01, 2009 10:13 am

#168500 - sgeos - Fri May 01, 2009 1:01 pm

#168501 - Ruben - Fri May 01, 2009 1:57 pm

#168502 - sgeos - Fri May 01, 2009 4:53 pm

#168503 - Ruben - Fri May 01, 2009 4:59 pm

#168541 - sgeos - Mon May 04, 2009 1:41 pm

#168542 - Ruben - Mon May 04, 2009 1:43 pm

#168786 - Ruben - Sun May 24, 2009 1:10 am

#168979 - Ruben - Sun Jun 07, 2009 10:13 pm

#168981 - gauauu - Mon Jun 08, 2009 3:10 am

#168991 - Ruben - Mon Jun 08, 2009 8:47 pm

#168992 - sgeos - Mon Jun 08, 2009 10:29 pm

#168993 - Ruben - Mon Jun 08, 2009 10:41 pm

#168998 - elwing - Tue Jun 09, 2009 6:31 am

#169001 - Ruben - Tue Jun 09, 2009 6:57 am

#169004 - elwing - Tue Jun 09, 2009 8:11 am

#169006 - elhobbs - Tue Jun 09, 2009 1:45 pm

#169007 - kusma - Tue Jun 09, 2009 2:42 pm

#169008 - elwing - Tue Jun 09, 2009 2:56 pm

#169011 - gauauu - Tue Jun 09, 2009 3:14 pm

#169012 - kusma - Tue Jun 09, 2009 3:39 pm

#169016 - elhobbs - Tue Jun 09, 2009 6:44 pm

#169024 - kusma - Tue Jun 09, 2009 7:49 pm

#169029 - Ruben - Tue Jun 09, 2009 11:33 pm

#169132 - Ruben - Sun Jun 21, 2009 3:38 am

#169136 - Ruben - Sun Jun 21, 2009 5:42 am

#169137 - sgeos - Sun Jun 21, 2009 11:40 am

#169146 - Ruben - Sun Jun 21, 2009 5:51 pm

#169147 - sgeos - Mon Jun 22, 2009 12:50 am

#169148 - Ruben - Mon Jun 22, 2009 1:34 am

#169149 - sgeos - Mon Jun 22, 2009 2:39 am

#169153 - Ruben - Mon Jun 22, 2009 5:06 am

#169157 - sgeos - Mon Jun 22, 2009 7:28 am

#169161 - Ruben - Mon Jun 22, 2009 7:57 am

#169211 - Ruben - Tue Jun 23, 2009 3:53 pm

#169223 - Ruben - Wed Jun 24, 2009 6:04 am

#169224 - sgeos - Wed Jun 24, 2009 8:05 am

#169225 - Ruben - Wed Jun 24, 2009 8:15 am

#169227 - kusma - Wed Jun 24, 2009 11:28 am

#169231 - Ruben - Wed Jun 24, 2009 1:55 pm

#169235 - vuurrobin - Wed Jun 24, 2009 8:12 pm

#169238 - Ruben - Wed Jun 24, 2009 9:58 pm

#169240 - sgeos - Thu Jun 25, 2009 2:02 am

#169496 - Ruben - Fri Jul 17, 2009 3:44 pm

#169775 - Ruben - Mon Aug 03, 2009 1:52 pm

#169776 - elhobbs - Mon Aug 03, 2009 2:24 pm

#169777 - sgeos - Mon Aug 03, 2009 2:25 pm

#169778 - Ruben - Mon Aug 03, 2009 2:36 pm

#169779 - gauauu - Mon Aug 03, 2009 2:39 pm

#169781 - sgeos - Mon Aug 03, 2009 3:26 pm

#169786 - Miked0801 - Mon Aug 03, 2009 6:01 pm

#169789 - DekuTree64 - Mon Aug 03, 2009 7:19 pm

#170590 - Ruben - Mon Oct 05, 2009 12:00 pm

#170592 - Miked0801 - Mon Oct 05, 2009 4:29 pm

#170593 - Ruben - Mon Oct 05, 2009 5:26 pm

#170596 - sgeos - Tue Oct 06, 2009 1:49 am

#170597 - Ruben - Tue Oct 06, 2009 2:05 am

#170598 - Miked0801 - Tue Oct 06, 2009 3:09 am

#170599 - gauauu - Tue Oct 06, 2009 3:36 am

#170605 - Ruben - Tue Oct 06, 2009 2:07 pm

#170606 - Ruben - Tue Oct 06, 2009 2:11 pm