DaFool wrote:
(It seems to me though that Western SRPGs are more likely to use hexes than squares, while Japanese SRPGs tend to use squares.)
To be honest, I'd say most SRPGs are more likely to use squares. I get the impression that games which use hexes are more likely to be more wargame-oriented than RPG-oriented, if that makes sense; RPG-related stuff - even down to stuff like the UFO/X-COM games - seem to me to stick with squares for the most part.
DaFool wrote:
The only styles I can think of are ATB and tactical, so maybe all Jake needs to do is create two basic versions of his battle engine: The Abraxas version and a standard tactical system where the gauge is based on movement distance instead of time would work perfectly.
Well, I can think of a couple more styles, but I'm also trying to allow for mix-n-match gameplay, in that regard. The plan so far is for there to be three main types of 'battlefield' which determine where fighters are placed and how they can target other fighters, and two main 'mechanics', which determine how the game decides which fighters to allow to act and in which order. These are fairly loosely-coupled, so if anyone can think of any extra options I'm happy to consider them, and it shouldn't even be too hard for people to write their own, with a bit of Python knowledge.
So there's a simple battlefield, which is just the straight FF-style line-up-against-each-other, anyone-can-target-anyone approach; there's a battlefield similar to the Abraxas style in the demo, where fighters move around on arbitrary paths and can target nearby enemies; and there's a grid-based battlefield where fighters move around on a grid and can target enemies in adjacent squares (targetting actually has a range component, but still).
And then there's an ATB-style mechanic, where fighters' initiative goes up over time and when it's full, they get a turn, and a turn-based mechanic, where each faction runs through all their fighters once before handing off to the enemy, who runs through all
their fighters once. So the game author could choose to have an active mechanic on a simple battlefield to emulate FF games, or a turn-based mechanic on a grid to emulate most SRPGs, or an active mechanic on a grid to do something different. (I can think of games which have done ATB-style prioritising on a free field, stuff like Grandia up to Eternal Sonata, but nothing on a grid comes to mind offhand.)
DaFool wrote:
So in summary, we just need:
* mostly VN engine
* about a dozen or so battle sequences, either ATB or tactical
* a Garage / Inventory screen
(Personally, I'm not planning to implement stuff like the garage/inventory screens - or anything else outside of the battles themselves. The battle system should support arbitrary (and customisable/extensible) items, equipment and skills, but how those get given to fighters is up to the game-maker, really. It should be possible to extend the classes to give fighters experience and change their stats accordingly, but I'm not planning on including something like that in the initial release at least. It's too game-specific, to my mind, not to mention that it's extra work that's easy to separate out from the battle system itself and isn't always necessary.)
DaFool wrote:
-move
-attack
-defend
-item (that replenishes or boosts stats momentarily)
-a special move that temporarily transitions to VN mode to display a custom Ren'Py animation sequence which is different for each character. Something along the lines of "Henshin! Gattai!" If there's one thing good the Japanese style has it's the ridiculous posing that's so entertaining and time-wasting.
That's it.
What I've done is created a Fighter class which by default doesn't know how to do anything at all, and has no stats. The game-maker can set up arbitrary stats as and how they want, and can also assign 'Skills' to fighters - classes which describe in-battle behaviour like "Move", "Attack" or "Cast Lvl3 Fireball" and can also demand that fighter has certain stats (and should default them if necessary). So while I plan on providing a decent number of 'normal' Skill types - including move, attack, defend and use-item - it should be possible for anyone with a reasonable Python ability to create new ones relatively easily.
(Cut-in animations I'm personally more inclined to do through Sprite classes, but still, I don't want to shut-out any possibilities I don't have to.)
DaFool wrote:
As for the grid, maybe a waypoint mesh or node system would be ideal? I plan to have mountains and terrain obstacles in my game so it's better to have a very flexible grid system.
Well, the way the Abraxas demo works is just that all the nodes are arbitrarily placed and linked. Which is very flexible, and allows for movement flowing more-naturally around obstacles, but it's a pain in the arse to actually place all the nodes. To do the ones in the demo, I opened the BG in Photoshop, drew the nodes I wanted over the top on a new layer, then noted down the pixel positions for each of them on a bit of paper, and had to write a line of code for each node and another line of code for each connection between nodes... which becomes a bit of a pain after the first ten or so nodes.
So if anyone has any ideas about how node placement could be made easier without also getting more confusing for the user, I'm all ears. My best idea so far is to write a separate stand-alone Windows app which you can draw out your nodes on and it'll export to a bit of Python code so you don't have to actually type it all out and measure stuff, but that's still pretty cumbersome.
(The main reason I'm planning to do strict grids as well as the node-maps is just that grids make it easier for people to lay out large numbers of nodes at the same time!)
(one of the major criticisms was the character that went 'nyan! nyan!' the whole fuckin time)
).