I don't know how I came up with the title of Escheron. I was trying to think of what to call the game world, and that's the first idea that came to mind. Awkward coincidence how it's similar to ESCHELON, the U.S. data surveillance network.

In terms of difficulty, will the game be more like the hard mode of Final Fantasy II (NES) for the Playstation, more like the hard version of FFVI or more like Ghost N Goblins hard?

The best comparison I can think of is the NES version of Dragon Warrior II + Final Fantasy II (the original Famicom game previously not released outside Japan) + some rougelike-lite elements.

FF4 Hard Type should be easier than Escheron. You can always grind your way to victory at any point in that game, whereas Escheron has a cut off point determined by so-called "safe zones."

You're not safe to leave the current area you're in until you've reached the highest stats the game will allow you to attain by fighting the enemies encountered in that area. At that point, you can move into a new area with tougher enemies, and these new enemies will allow you to resume grinding your stats to higher values. All of this is controlled by the rank system mentioned earlier.

If you try to venture into a different zone too early, not only will you not even be able to damage any of the enemies there, but they'll probably kill you with a single attack.

There are a few other things worth mentioning that really kick the difficulty up a notch:

 - A lot of enemies at different stages in the game have access to instant K.O. spells. Resistance to this effect is determined the target's maximum HP. The weaker K.O. spell is no longer effect against a target when it's maximum HP is above 40, and the strongest K.O. spell won't affect targets with over 128 HP.
 
 The early to mid-game sequences will be pretty daunting for this reason. Maya should have over 128 HP by the time she reaches the final dungeon, but due to cut offs and safe zones, she definitely won't be able to attain that much HP before then. Just hope you don't get ambushed by any spell-casters half-way into a long dungeon.

 - Armor has a weight factor that penalizes reaction speed. Reaction speed determines battle turn order, preemptive strike rate and probability of fleeing an encounter. If you aren't careful, you will not only ensure that Maya is consistently ambushed by every enemy she encounters, but that she also can't flee from them.

 - If Maya tries to attack fire-based enemies directly, she'll be burned. This is a pretty straightforward counterattack mechanism. To make things tricky, there are a few enemies that are not only fire-based, but have ridiculously high defense power.
 
 This counterattack formula is based <i>only</i> on Maya's raw attack power, not a percentage of how much damage she actually dealt to the enemy after its defense power had been factored into the equation. In other words, Maya may be able to inflict maybe 1 or 2 points of damage with an attack, but she'll suffer an upward of 120+ damage as a result of coming in contact with the enemy's flames. Thankfully, critical hits don't return additional damage against Maya.
 
 Magic spells ignore defense power since there's no special type of defense against magic, so these enemies aren't extremely challenging as long as you have plenty of MP to get you through hoards of random encounters with them. Alternatively, you can just run. You'll be doing a lot of that anyway.

 - The attack formula used by undead enemies is different from the standard attack formula used by both Maya and most typical enemies. Undead attacks shave off a direct percentage of Maya's maximum HP, ignore her defense power, and heal the enemy in return. This means undead enemies encountered in the very first areas of the game are still just as deadly even after you've been to the final dungeon and back.
 
 On the other hand, undead enemies have frail bodies, little HP and the lowest defense power in the game. As long as Maya is fast enough to get the first attack, she doesn't have to worry. Undead enemies are mostly a problem early on when they appear in large groups, because Maya won't have access to a multi-target spell until the middle of the game. But...
 
 - There are (rare) enemies that are both fire-based and undead. The counterattack damage will render your HP critical, then the enemy's actual attack will probably finish you off. If that doesn't do the trick, then their instant K.O. spells will.

A subproject is currently being worked on, which has largely been kept a secret until now. We call it Aegis-Rin.
Try not to think too hard about the name. I didn't when I named it.

In short, it's planned to be a fully modular RPG engine. Me and geekboy has this entire project planned out and are working towards the goal of completing it in a reasonable time.

What we have: Text script system (fully programmable, with its own stack and registers), custom font driver, tilemap renderer and loader, tileset loader, an honest-to-god sprite routine (!), movement and collision detection.

What we don't have yet: Event system (current tile ID, current position [hotspot], timer-based (either realtime or based on steps/actions), interact-key), example scripts to recreate things such as menu systems and NPC dialog, and the PC-side tools needed to pull together the data needed for the loaders to work.

At the end of this subproject, we will have created a fully functional test RPG that does all the things that a much larger RPG (such as E:SoR) should be able to do. The test should be short, easy, and silly. Hint: It's about cherries.

Also the joy of the text system/script system we have in place is the ability to handle math inside of it in a lot easier fashion then pure assembly.  So we can do more complex math to give the game a better feel to it! Oh and it's probably Turing complete, mini games anyone ;p

I did not catch up on this thread but it's nice to see a large RPG is being revived. I wish you luck guys.

Since Iambian is still poking around, there's something I wanted to ask him:

How do you feel about the direction of the project? I've done a few rewrites on account of some of the difficulty we had with the original grayscale concept. Do you think we should officially move away from the old assets and stick with the newer, more simplified design? (i.e. The recent mock-ups I posted)

So I have a question for you. Would you be against the idea of quick saves? Or if we have the ability to implement them should we? I feel that on the platform we are programming this for it would be unwise to not be able to exit ... err promptly.

I guess it could be implemented, as long as it doesn't aid in save scumming. A quicksave file would have to be erased as soon as its resumed.

an honest-to-god sprite routine

About time.

I'm still going to keep the old assets as it's just another folder. An additional project can be made in b/w, but after the subproject is finished. People are expecting a full 4 level grayscale game, and they've been waiting for it for ages. We're gonna deliver that at some point.

Also, I wouldn't be worried about save scumming on the calcs, since most of the time, yanking a battery while running a typical assembly program results in data loss. Most people wouldn't think of doing something like that to try save scum. They might do things such as rename/copy files. If you wanted to protect against save scumming, you would want to keep something of a counter on hand to check against the version of the save file being presented. If there's a mismatch, then you could call them out on it.

There was actually some suggestions in HCWP (off-day) that involved using MD5 hardware and messing around with the certificate page. I suggested writing to the boot code if the calc is a newer model, but that suggestion got shot down and I then suggested writeback to the app.

I don't think I'm going to make the protection too strong, but I am going to make it such that if you want to cheat, you're gonna have to work at it.