Thad wrote:I was playing Tactics Ogre last night. I've been sticking to chapter 1, doing a bit of grinding so I can get some variety in my squad instead of just going into chapter 2 with the original stock characters and classes.
And you know, it's one of those games whose Pure Gameplay is solid enough that grinding is pretty fucking fun; the worst thing about it is the lack of different maps you can go to to grind. (This is a problem in chapter 1 and, IIRC, an even brobdingnagier problem in the next couple of chapters. It's a problem in the early going in FFT but not nearly as brobdingnagian of one.)
And it occurred to me, hey, what this thing needs is a level editor.
And then I thought, why not go all the way and make an entirely mod-friendly tactical RPG in this style?
[...]
it appears that people have thought of this, and made some attempts, but there hasn't really been anything fully-fledged in that direction in a very long time, which is a pity.
I'd love to see someone do it as a full-on GPL editor suite, multiplatform (because TRPG's work great with mice and possibly even better with touchscreens).
I've been putting a bit more thought into this, and I've been pondering logistics.
At its very simplest, proof-of-concept stage, a tactical map would consist of a simple bounded grid with two player-controlled characters on it with move and damage stats, taking turns.
I'm going to split this up into different areas and increasing levels of complexity from there.
Terrain
From simple bounded grid, the next step up is to have two types of tiles -- ones where characters can move, and ones where they can't.
From there, the next move is types of terrain that interact with characters' movement and actions (eg water). You could also work damage tiles, and FFT-style Geomancer region types, into this stage.
More complex from there is the third dimension, adding heights and a Jump/Climb/Whatever character movement stat. This, by necessity, moves us out of a simple top-down perspective and into an isometric one.
And then from there you can go to those multi-layered maps FFT has (where the same xy spot on a map has two different places to stand on the z-axis), if you wanted. I'm not sure I'd really be interested in that, but it's an option.
Combat
From the simple two guys with one stat idea, you branch out to more stats -- attack, defense, evade; equipment to modify them. Different kinds of damage, like physical versus magical.
From simple attack-the-guy-next-to-you targeting, you'd go to ranged attacks that can target a square regardless of obstructions (eg spells), and then two-dimensional ranged attacks that can target a square but will hit an obstruction (like crossbows), and then three-dimensional ranged attacks (like a longbow).
Somewhere in there you implement direction -- increased evade against face-on attacks, etc.
And of course the hardest part's going to be AI. On a basic level, you give each computer-controlled character an objective ("Heal", "Attack", "Tank", etc.) and do a minmax calculation every turn. (The results of the action -- whether or not it hits, how much damage it does -- can be randomized but I think the decisions themselves should be deterministic, always give the same output provided the same input -- you want that if you're going to allow TO PSP-style backtracking, which I'll get to later.) That sounds simple but there major details to consider -- the biggie being finding a balance between lookahead and a playbook. Lookahead is computationally prohibitive and should probably only be implemented in a very basic sense ("that knight is close enough to kill that mage, can I get close enough to heal him without endangering my own life?"), but that means having a pretty complex playbook put together, a lot of play testing and some very thorough understanding of different situations parties might get into.
Character Growth and Stats
There are a whole lot of different ways to do this. On the whole I'm inclined to follow FFT's style -- character growth with actions, each character having a level and a job and earning points toward both, and a job system where you master low-level jobs to gain access to higher-level ones. I don't think I'd fuck around much with game-breaking specialty classes, though presumably that option would be trivial to add.
But there's some appeal to a system like TO PSP, too, with jobs leveling instead of individual characters. The downside in that implementation is every job starting at level 1; there'd need to be a way to balance that. Maybe combine it with FFT's tiered job system and make level 1 of a prestige class be the equivalent of level 10 of its prereq class.
If we're looking at full-on toolkit, I kinda like the idea of multiple different options, but for an initial build I'd keep it simple.
Beyond classes, there could be a race system involved -- different races have different base stats, and certain classes are only available to certain races.
Somewhere in-between are monsters -- no equipment, no class, each effectively a class unto itself. In that case I'd prefer a system more like TO's where there are still a variety of customization options.
Timing
Early in development I could keep it strictly turn-based -- everybody on one side moves, then everybody on the other; maybe start with a coin toss to decide who goes first.
But to do it up right, you need to not only define a rate-of-movement stat, you need a system that shows the next 10-20 moves ahead, and updates itself as it changes (somebody dies or has some sort of status alteration affecting move order).
Persistent memory that lets you go back to earlier moves, like TO PSP, would be pretty simple to implement from there.
Next step from there would be FFT-style charge time on spells and other moves, but I'm ambivalent on that. It was one of the most complex elements of FFT's play, and/but one of its most irritating and frequently crippling (it made Cloud useless and archers pretty much the bullshit class you stick with until you can become a thief).
Dialogue Trees and World Map
These are some of the simplest things about FFT/TO; every spot on the world map is either a fight or a shop, and dialogue doesn't tend to have more than two options at any given time. Even going for a system like TO's where your decisions determine the path of the game, this is trivial stuff; checking available destinations based on past decisions is easy.
File Formats
We're looking for a few different things to record here: world map, individual combat maps, shops, class trees, dialogue options, possible enemy parties (and names for them). For the player, you've got individual character stats and story progress.
All of that stuff would be pretty trivial to store in a human-readable text format -- XML, JSON, or something just made-up. Text tends to be a pretty inefficient way of storing data, but that's unlikely to make much of a difference; we're talking about games that will have graphics and audio, and even uncompressed XML is going to take up less space than even simple sprites. If I really wanted to I could feed it through a compression algorithm but that'd probably be unnecessary.
A simple, human-readable data format would make cheating trivial, but I don't think that's a bad thing. People who want to cheat can cheat, and it's a great way to learn how a game works. I want modding to be a feature, not a bug, and the lower the barrier to entry the better.
Editor
Another argument in favor of human-readable file formats is that they could precede a GUI. Allowing full customization before the GUI's even put together wouldn't exactly make for a killer feature for end users, but it might attract enthusiasts early on and it would work well for proof-of-concept games.
Long-term, I'm picturing something that looks a lot like Populous. Simple, graphical raising and lowering of terrain, defining terrain type, enemy placement (deterministic placement for scripted events, semirandom placement for random fights). And really, that shouldn't be too difficult to implement after the game interface is already built; they should be pretty similar.
Engine/Toolkit/Language(s)
Unity looks like it's the easiest way to build something for multiple platforms with multiple input methods. The downside is that it's proprietary, which makes it another barrier to entry. Again, I want this to be as moddable as possible, and that includes being able to recompile from source and redistribute modified versions. I'd like people to be able to do that without needing to buy a Unity license.
So what about just having it run in a browser? HTML5/JavaScript. That'll run on anything, but puts me at a disadvantage as far as existing toolkits to start from. I'd probably take a look at projects like BrowserQuest, see what's already been built. But here we get to concrete "Where do I start?" questions, and those aren't as easy as the hypotheticals.
Anyway, that's what I've been thinking about. Really preliminary stuff, but still a pretty brobdingnagian wall of text for all that.
Oh, and one more:
I want to focus on the engine, but if I ever got the thing finished enough to make an actual game about it?
The Setting
Why not go urban fantasy?
Of course, the thing about urban fantasy is it really should be set in something that's at least a close approximation of a real-life city.
So that would limit it pretty much to places I know -- like, say, my hometown.
...and so it all comes back to me trying to make games about where I went to high school.