Auto re-targeting has been a major pain, but I think we've agreed that, rather than re-target if the original target is destroyed en-route, the character would instead use their turn to defend. There would otherwise be too many exceptions involved in how a character should re-target in the case of using curative spells, or abilities with complicated targeting parameters. At least this way the character's turn isn't necessarily wasted - i.e., as it was in Final Fantasy I: "Fighter attacks enemy corpse. The attack was ineffective!"

Ugh, that could definitely be a pain in the neck. Good luck with this, then; I hope it's a success.

I'M glad that this project is progressing again. Keep up the good work guys!

Definitely agreed. I've seen the usual trend this fall of a whole host of games and projects being completely abandoned because the authors suddenly found themselves with little or no free time, and I'm glad that this isn't one of them. I wish even the people with no time would set aside 30 minutes a week just to stare at their code, make a post that the project still exists, and keep themselves in the frame of mind of programming even if they don't have time to make any actual progress.

I don't think you have to worry about Escheron becoming vaporware. Although we might be kind of slow on the progress updates, the game has been progressing all this time. (aside from the occasional break, or planned hiatus) It's just a slow development because it's such a robust game, and there are only two people working on the project. A lot of detail goes into the intricacies of an RPG engine, after all.

As I see it, the battle engine and sprite routine are the two biggest obstacles to surmount. Once those are completely out of the way, the game is basically done.

Har har har. After all has been said and done, the routine weighs in at 199 bytes. About as close to 200 bytes as I expected

The default action *is* to automatically retarget any available characters/enemies, so you *will* end up wasting that healing spell if the recipient dies or something. Works the same way with reviving dead people, though now that I think about it, such an even would be impossible (two dead guys can't be both revived by a single character).

If an alternate target cannot be acquired for any reason, the character will defend (parry) instead.
-----
Also, another big obstacle would be putting in the mountains of text and having a reasonable way to display them with respect to who you talk to. And events. Especially the automated kind.

Great to hear, keep up the good work! And just to clarify, I was using you guys as an example of a team that was skillfully avoiding the traps of vaporware by continuing to at least slowly make progress.

In addition to automatic targeting, I'll have another routine that determines whether or not the user is "available" to perform any given action when his/her/it's entry is placed onto the command queue. This command queue contains the actions of every entity that wants to participate a fight's round. It is modified only when entries are needed to be inserted (in the case of extended attacks that perform more than one action), but entries are never removed from it once the queue has been constructed.

What controls what entry does NOT happen is whether or not the target is either dead or "enchanted," however that is defined in the design documentation. What this scheme accomplishes are as follows:

- When a battle participant becomes "unavailable," there is no need to scan through the table to remove entries. The check is made each time an entry needs to be acted upon.
- Since entries are not removed, there is an opportunity for participants to become "available" again in the same round, so their move isn't destroyed when it comes time for them to act. For example: A participant removes "enchanted" status from another before their turn comes around. By the time the formerly "enchanted" participant's turn comes around, there is nothing impeding him/her/it from taking some action.

Aside from special processing that certain commands may perform, I got this down solid.

EDIT: There's no chance of me forgetting about important parts of my code. Even if I may forget *where* in the project I put them, I won't ever forget them. Too much time was spent trying to build this thing up, and I'm rather proud of my accomplishment to date. Some of these things were downright painful to produce. Can't forget about that

But don't you lose some of the intricacies of a section when you move on to focus on another section? That's what happens with Doors CS; I find it hard to cache the entirety of 48KB of functionality in my mind at once. Nevertheless, thanks for the in-depth explanation, very interesting.

It's also worth mentioning that there's a prequel for Escheron in development. It's a radically different gameplay style, but also a much less robust game. You assume the role of a single hero, and guide him across a series of battle maps until you reach your ultimate objective. It's a similar gameplay style as Shining Force, Final Fantasy Tactics, or other turn-based, strategy RPGs.

The working title is something like "Presage of Darkness: A Chronicle of Escheron." It simply puts some of the game world's history into better context, without any actual character tie-ins.

Woah that looks great, as always! I assume this would be designed for BASIC+libs, right? It seems like it could be doable in that language.

Seconded, this does indeed look great, as expected. I'm equally curious if this is to be Hybrid BASIC or pure z80.

Not sure what the language would be. I suppose Iambian would be doing the coding, if he feels like assisting with the project. It's likely he would want to use ASM.

At least the game should be able to run on regular 83 models. That's what I'm aiming for, so the game is more compatible with older models than Escheron is.

That would pretty much preclude Hybrid BASIC and any shell newer than Ion 1.6/Doors CS 5, then. Sounds great though; since my first calculator was a TI-83, for quite a long time into my ASM career I tried to make all my projects IT-83-compatible.

I thought I would share a couple of earlier mock-ups I did for Rephaim, which demonstrates how some of the summoned monster sequences would work. (although, these are just ideas at the moment)

Looking great!

That is great. Good job for Grayscale!

Wow, that is extremely effective use of grayscale, Zera! Mad props.

Restarting the project. Too many hacks make it unmanageable.

Using SPASM now. It is GOD compared to TASM.

Yup, and better than both is Brass, of course. Good luck restructuring everything.