Indeed, the LCD issues. Sorry to hear that this prroject is on hiatus until it gets repaired; are any of your or his projects taking up the slack in the meantime?

I'm not sure what the idiom, "taking up the slack" means.

In this sense, I mean taking your coding/spriting time while you're idling on E:SoR, or if there's not really a void to be filled.

Oh. Escheron is pretty much complete, as far as its assets go. The only work I really need to do there is finish editing some parts of the script. Inserting the script will probably come some time after the battle engine is out of the way.

I've been working on other projects while Escheron is in its coding stages; so they're always fairly active.

You should tell us about those other projects in the meantime, then!

The details of other projects are pretty scattered. I'm not sure if I have enough consistent detail to give adequate synopses of them.

One project I wanted to develop on at some point is Euzora. It's an RPG based on a futuristic setting, and involving a territorial conflict between Brahmans and Mitra. Mitra are the native inhabitants of the planet Euzora, whereas Brahmans settled on their planet sometime ago. The Brahmans lost their homeworld to a world-war, and set out to find an uninhabited world that would pose a suitable home for survivors of the war.

Having grown weary of space-travel, they finally settled on Euzora. Initially, the Brahman political leaders claimed Euzora was uninhabited, and attempted to oust the Mitra, and hide their existence from the general public. Eventually, this cover-up became too difficult to continue; so the Brahman contrived that the Mitra were actually invaders from another planet, and used this to justify engaging them in a territorial conflict. At some point, Brahman scientists proposed using the Mitras' psionic capabilities as a source of energy. Because many people believed the Mitra were hostile extraterrestrials, few objected to enslaving the Mitra to better their own lives.

Many years later, a political resistance faction surfaced, claiming that the Brahman government has woven many lies about Euzora's history, and the nature of the Mitra. The player would take on the role of several characters within this resistance, and attempt to fight their way through government forces to expose the truth.

Gameplay-wise, the game would feature a real-time system. Exploration and combat would all occur on the main maps, with no need for transitioning. Character development would occur in a system involving a growth tree. As characters gained ability points through battles, (or missions) they would be allowed to choose one of three status or ability growth paths. When a choice is made, the character progresses down the tree, and three new options are made available. This goes on until the character reaches max level.

The stats and abilities that are gained in this manner are all predetermined; but you don't have any way of knowing what exists on subsequent paths. (unless you've already played the game and took the time to map it out) It tends to make character growth somewhat unpredictable; but each choice you make would have a logical consequence. e.g., if you choose a Strength path in a previous level, then it's very likely that another Strength path will be made available to you down the line. You can logically diverge from this path by choosing something opposite to it the next time.

Conventional RPG equipment doesn't exist. Characters each have one unique weapon, which can be modified over and over again to add new stats or abilities. Each weapon has a defined number of slots, and modifying them is simply a matter of inserting components into these slots. Each component has its own stat bonuses, or abilities. These can be freely removed and swapped with other characters, as well.

Abilities are learned through the growth tree system. There are times when you can choose to learn a new ability, rather than raise a stat. Abilities range from combat skills to psionics. (rough equivalent of magic) All of your passive abilities (such as a chance to counterattack) are tied to your weapon components.

Wow, that's certainly a more thorough and complete response that I had anticipated, Zera. The game sounds like tons of fun, and I think would be unique from any existing calculator game (I'm assuming it would be for calculators, right?) in terms of the gameplay mechanics and, it sounds like, the craftiness of the backstory and storyline. It sounds like a pretty huge project, though; how much of it is complete? It sounds like it's still in the planning stages, correct? At any rate, I hope you have the time and inclination to attack that at some point, it sounds wonderful.

It's just in planning. No assets have been created. It would ideally be for 15 MHz calculators.

I wanted to have more robust sprites than what I normally work with, but it would probably mean having too many assets. I have to find the right balance without sacrificing too much detail. Maps are another debate. I thought about having everything pre-rendered, but that's hard to do without bloating the game way too much. The idea is to make a pretty restricted range of maps, but try to include as many things to do in them as possible. Perhaps the entire game would take place within a single city, where the primary mission focuses on overthrowing this government. On the other hand, the player would have the choice of pursuing optional missions that extend the overall gameplay experience. It would just all take place in a very limited amount of area.

What do you mean by more robust sprites, exactly? Better masking? More gray levels? Larger size? Animations or more exhaustive animations? Some combination of the above, or something I didn't think of? And I definitely like the idea of trying to make a smaller map very versatile rather than a more spread-out but more linear worldmap.

Just a lot of sprites. Sprites for turning diagonally, executing a number of different moves, and so forth. Anything else I've worked on just had a handful of sprites for basic up, down, left, right movements.

Real-time games demand a lot of graphical assets. Whereas Escheron has static bitmaps of enemies, for instance, a real-time game would need several variations of enemy sprites to represent their various movements and attacks.

Definitely, and I bet that will be a big challenge. I was boggled just by the space required for a few static 3-level sprites when I was planning Civ Sim II. I think it's a good ambitious goal to work on that at some point though, and I hope you do.

This makes me with I had a 89 again. The stuff made for those are so much more impressive than the 83 series. Anyway, looks like a great game. Graphics make the game and this game has got graphics!

Well, both graphics and gameplay in my opinion. No point having awesome graphics if you have no gameplay to back it up, and great gameplay is unimpressive without some eye candy, imho. This seems to have both though, from what I've seen. And yeah, the 89 can have more impressive stuff thanks to C, a larger screen, and much larger memory space. :/

Gameplay and story. That is all.

Wait, what? You don't think graphics have any bearing on how good the game is?

On the subject of other projects, I'm also working on a game titled Lost Legends. Here's a reference map. (the game's first village) The project is actually a reboot of some much earlier ideas that never got off the ground. I wanted to resurrect it as something much more robust.

Bump. Small bit of progress. (cross-post from Omnimaga)

Working on an automatic re-target function for E:SoR's battle engine. The specifics are as follows:
1. Obtain target flags for those that are still alive.
2. Invert flags if you're trying to target the dead.
3. Compare (AND) with what you are actually trying to target.
4. Load target flags back to attack slot and return IF the AND function returns nonzero.
5. Attempt to re-target based on probable use (i.e. If target a character who's dead, try someone else)
6. If attempting to find a target fails, change character action to "Parry". Note that this *can* happen under certain circumstances without the battle engine declaring victory or defeat.

So... Yeah. I haven't got point #5 down quite yet. Point #6 should be easy once #5 is done.

I'm curious, when people write "cross-post to/from Omnimaga" here, do they write "cross-post to/from Cemetech" there?

At any rate, this seems like a great idea, and will be another good guarantee of gameplay fluidity and a way to avoid a clunky interface. Do you have any idea how much codespace this is going to cost you?

Man. Made me feel bad about the whole crosspost thing, so I tacked one on the Omnimaga thinger too.

I don't expect the code used for automatic re-targeting to take up much space. I actually needed one such routine anyway. All the other routines expects target information to be accurate. As in, if it's gotta do something, it's gotta be effective. Otherwise, you'd end up doing something like hitting an enemy with 0 HP and suddenly it has OVER 9000.

EDIT: Didn't actually answer the question. I'm thinking 100-300 bytes will do it. Out of an available 1200 bytes.

EDIT2: It's actually 1471 bytes left for the function. The current run of code uses 119 bytes and is expected to grow close to 200.

Very nice, I see you're planning on cutting it as close as me with DCS7.1 once I packed the Cn2.2 routines in. That makes a lot of sense about why it's important; thanks for explaining.