I've reworked the code slightly to allow me to easily increase the resolution at a later date if I decide to do so. Well, "easily, not including actually making the higher-resolution graphics", I mean.

All I have to do is change a single constant, and slip in the higher resolution graphics. This is good - I'd like the graphics to be of a decent resolution for the final product, but if I try to achieve that while still making the engine work, I'm going to spend too much time on the graphics (instead of making crappy placeholders) and not enough on the coding - that was an issue with the first remake attempt.

I also implemented another change that looks really nice. See if you can spot it.

EDIT: And I've now implemented some more of the menu system, too.

Good news everyone! (What are there, 4 of you? )

This is a small forum, but there's a bit more than 4 active members. Maybe closer to around 20.

Me, I've been reading this thread but haven't had anything worthwhile to post in it so far.

I was getting a bit burnt out working on the battle system for now, so I decided to start developing the menu system.

While it doesn't have much at this stage, a quick glance might already hint at some new features I plan to implement this time around. I'll be basing it off how FFX handled it, though not an exact clone (I plan to draw some inspiration from FF8 here too, although it'll be much closer to FFX).

On a side note, this is also the first new engine screenshot I've shown that shows the field screen, too. This is just a test map, it's not in any way intended to be part of the final game. (The tileset, or at least some of the tiles, likely will be used though.)

NeoLemmix has more skills than Lix (17 to 15).

I think he means how many different skills a single level can have. If I'm not mistaken, a single Lix level can contain almost all 15 skill types in a single level (aside from the two different bombers). NeoLemmix may have 17 to choose from, but any individual level is limited to using 8 of them. Although I do have to wonder if this may need to be expanded, especially with even more new skills on the horizon - not perhaps to the extent of no limit, but maybe expanding it to 10 or 12. Even prior to the introduction of the Fencer, I've hit the skill type limit from time to time when designing levels. Assuming not too much has changed since I was maintaining it, the biggest difficulty with this would be fitting it all onto the skill panel nicely, especially for the compact layout - outside of that, IIRC it's just arbitrary hardcoded limits.

Attacks finally do something!

There's still a long way to go. You still can't select an enemy target other than the default one (I'm still not entirely sure how I want to implement this), though you can choose to target an ally instead (and you can select which one). If you could, you'd probably be able to select dead enemies. Enemies also have no AI whatsoever - they just repeat the last action a party member made, including the target. And there's no animation for the attacks, apart from displaying the damage. Also, while enemies do disappear when killed, the game doesn't at all recognize "all enemies have been defeated, time for the battle to end" yet.

Still, it's progress!

A bit hard to capture in pictures, but I made some significant progress on the battle system today.

The turn order - including different delays from different attacks - is now fully implemented! You can select attacks and pick targets for them (though the attacks don't actually do anything, except display their name if applicable, currently). Changing enemy target isn't yet implemented, because this will be a bit more complex than changing targets among allies.

The reason for this - allies are always in a line top to bottom. You press up, you go to the ally above the currently targetted one. Press down, you go to the one below. But enemies aren't always so straightfoward - they could be in just about any formation, really. And I need to think of how (in terms of coding - I know, from a human point of view, what should happen) to implement proper selection with this. It might seem simple at first, but think about situations like this:

Enemy A is at (10, 10). Enemy B is at (30, 9). Enemy C is at (26, 5).

If I'm currently targetting Enemy A and I press Right, yes, enemy B should be targetted. That's obvious, and easy to code.
But if I press up, what should happen? I feel that Enemy C should now be targetted. But what formula can make this happen, without hardcoding every single case? Enemy B is closer to (but still above) Enemy A both in terms of vertical distance only, and in terms of total distance (I think; I didn't actually test the numbers to make sure he really is closer).

But maybe enemies don't need to have complete positional freedom. If there are only a certain number of "slots", this could be handled much more easily. Perhaps the enemies could even be graphically offset from their natural slot-based positions, and the slots are used purely for target selection purposes (and tiebreaking in turn order; the last resort factor is "the ones listed earlier in the formation get their turn first". Before resorting to this, the game first uses the Agility stat as a tiebreaker, and if there's still a tie, it then uses a priority of "Characters, then boss enemies, then regular enemies" - only if all that still leaves a tie, the in-formation order is used, rather than bothering with yet another tier of tiebreakers.)

There is a slight random effect on how quickly a character / enemy get their first turn - and Luck stat indeed affects how likely you are to get a favorable outcome (in this case, it's just the character / enemy's Luck stat outright; not relative to another battler's Luck) - but there's no randomization at all involved in subsequent turns. Using the same test scenario as before over several trials (about 15 or so), looking at the first six turns of battle, only one trial deviated from "Red Girl gets three turns, the other battlers get one each" - in the trial in question, Blue Girl got none and the enemy got two; beyond that, the randomization only slightly affected the order of these turns. So it is a fairly minor effect. And of course, you could always avert that by equipping Pre-Emptive (not yet implemented, but I 100% intend to add it) to get a turn immediately at the start of battle.

EDIT: Wait, the Duck wasn't there last time I specifically focused on turn order in this topic. He has 11 Agility. (And just for the record, I don't intend to have a duck as one of the playable characters. If I use the duck graphic at all, it'll likely just be as a background decoration thing. I'm simply using it during testing because I made the graphic and so it's handy.)

Latest feature: The delay of the selected attack is now reflected in the upcoming turns display. Also, the order is now left to right. This feels more logical to me, even being used to the right-to-left order from the original game. (FFX didn't influence this decision, since FFX displays the upcoming turn order vertically.) The fact that the current turn is slightly raised above the others - and also now has a different colored border - should be enough to make this clear, I hope.

For the record - delays of different moves is a straightforward multiple. In these screenshots, Attack has 1x delay, Item has 0.75x delay, and Escape has 0.5x delay. These values are very much not final (I simply picked some for testing), except for Attack (since my intention is for it to be the standard that these delays are relative to - of course, on a technical level, that's purely a matter of "it definitely will have a 1x delay").

For now, my main focus is on getting the basics of the map and battle system in place (in the case of the maps, a significant portion of it already exists). Then from there, I'll most likely add further features as they're needed, rather than adding a whole bunch of stuff that "might be useful".