Fucking Tactics, How Do They Work?

User avatar
Thad
Posts: 13165
Joined: Tue Jan 21, 2014 10:05 am
Location: 1611 Uranus Avenue
Contact:

Fucking Tactics, How Do They Work?

Postby Thad » Tue Apr 01, 2014 11:12 pm

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 bigger problem in the next couple of chapters. It's a problem in the early going in FFT but not nearly as big 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 big 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.

User avatar
Thad
Posts: 13165
Joined: Tue Jan 21, 2014 10:05 am
Location: 1611 Uranus Avenue
Contact:

Re: Fucking Tactics, How Do They Work?

Postby Thad » Fri Apr 04, 2014 12:49 am

I haven't talked much about the graphics, because (A) that's high-level stuff that can come after the thing actually works and (B) I'm not very good at them.

But bringing up urban fantasy DOES bring up a consistent problem with games of this type: the lily-white cast. It's bad enough in a fictional fantasy setting, but if you try to tell a story that's set in a modern city and everybody's white, well, you're not doing it right.

Extremely simple and rough solution: assign all non-story characters a complexion -- light, medium, dark. Make them simple palette swaps.

No, it's not an elegant or a perfect solution. But it IS an easy one to implement. And I think it's a lot better than not addressing the issue at all.

User avatar
nosimpleway
Posts: 4514
Joined: Mon Jan 20, 2014 7:31 pm

Re: Fucking Tactics, How Do They Work?

Postby nosimpleway » Fri Apr 04, 2014 8:27 am

If you completely randomize hair and skin colors so they're not based on one another, it'd probably encourage an urban punk sort of aesthetic. So that may or may not fit depending on how grimdark you want the setting to be.

User avatar
Blossom
Posts: 2297
Joined: Mon Jan 20, 2014 8:58 pm

Re: Fucking Tactics, How Do They Work?

Postby Blossom » Fri Apr 04, 2014 1:33 pm

I would suggest that "moddable tactics engine", "the gameplay mechanics of my game", and "the setting/trappings of my story" are three entirely different categories and you might want to hash them out individually.
Image

User avatar
IGNORE ME
Woah Dangsaurus
Posts: 3679
Joined: Mon Jan 20, 2014 2:40 pm

Re: Fucking Tactics, How Do They Work?

Postby IGNORE ME » Fri Apr 04, 2014 4:12 pm

I'm just excited for any game named "Fucking Tactics".

User avatar
Classic
Posts: 1025
Joined: Tue Jan 21, 2014 6:53 am

Re: Fucking Tactics, How Do They Work?

Postby Classic » Fri Apr 04, 2014 4:43 pm

Wasn't there an LP of exactly that on the old boards?

User avatar
Thad
Posts: 13165
Joined: Tue Jan 21, 2014 10:05 am
Location: 1611 Uranus Avenue
Contact:

Re: Fucking Tactics, How Do They Work?

Postby Thad » Fri Apr 04, 2014 11:46 pm

TA wrote:I would suggest that "moddable tactics engine", "the gameplay mechanics of my game", and "the setting/trappings of my story" are three entirely different categories and you might want to hash them out individually.


The story/final game is absolutely separate and distinct, and that's why I haven't spent much time talking about it. It's something to maybe keep in the back of my head, but if I were to focus on it I'd be putting the cart before the horse. I see this as very much a Neverwinter Nights type of situation -- I think NWN had a fantastic fucking development engine and the main campaign felt like an afterthought. I want to lay a solid foundation; that in and of itself will be a success no matter what I end up doing with it.

Engine and mechanics are different but pretty inextricably linked. The mechanics are a roadmap for what the engine needs to be able to do; they certainly don't need to be fully supportable at the earliest stages, but they need to be considerations. Basically I don't want to take any shortcuts that make it impractical to do the things I want to do later.

Course, we're still at the very earliest stages here -- the conceptualization, get-the-ideas-written-down period, to be followed by the figure-out-an-engine-and-codebase period. But I think this has greater potential to be something I actually do than any of the other ideas that have been bouncing around my head for ages, precisely BECAUSE I'm thinking about the engine and mechanics first rather than the story.

(Of course, the game I got the farthest along on was Tempe High: The Zelda Quest, and the reason I never finished it was that the item distribution started to get boring. I stuck two science levels in a row, and what the fuck do you do there -- give the player the Red Candle right after the Blue? That's dumb.

The original Zelda's actually pretty flawed from an item distribution standpoint; level 1's item is useless without a separate item bought in a shop, level 2 has no item at all unless you count the Magic Boomerang, 3's item is just a funny-shaped key, 4 and 5 both have transportation-based items that also double as funny-shaped keys, 6 and 7...well, 6 and 7 actually have pretty great items, and then 8 and 9 are mostly endgame stuff plus the book which is not very useful. I'm not saying every game should follow the every-level-has-an-item-you-use-on-the-boss formula that started to take shape in LttP, solidified in LA, and became an Immutable Rule in OoT, but...well, I felt like I'd written myself into a corner by the time I got around to the last few levels. I'm still pretty proud of the maps, though.)

nosimpleway wrote:If you completely randomize hair and skin colors so they're not based on one another, it'd probably encourage an urban punk sort of aesthetic. So that may or may not fit depending on how grimdark you want the setting to be.


That's a pretty great idea; I'll file it away in case I ever get this thing far enough along to do anything with it. There's probably a simple way to swap color palettes on PNG's; I'll look into it.

My instinct is that if I went the UF route I wouldn't go full grimdark but I'd play it straight. Comedy is hard; look at the output of Zeboyd Games for some examples of games with solid mechanics that try way too hard to be funny and mostly just serve up warmed-over observations about JRPG's that we all stopped laughing at sometime around the turn of the century.

I mean, I COULD make a game where people ask why the fuck they can't wear sunglasses and a hat at the same time and why they're limited to only one ring, but would I want to PLAY a game like that? Probably not.

(Though I just started Bard's Tale and have to admit I like the bit where the tutorial guy starts explaining the controls and the Bard observes that he is just gibbering like a crazy person.)

I've mentioned Seeing Things, by Kater Cheek before, and I think that's a good example of a UF book that sets the tone I'd like to go for. It's not a comedy but it's not dark, either; it's a world where there's magic and vampires and shit but it doesn't dwell on the supernatural horror; it's more about a little college town where everything's a little bit weird.

But again -- all that's just idle musings for later. The engine and devkit come first.

User avatar
Thad
Posts: 13165
Joined: Tue Jan 21, 2014 10:05 am
Location: 1611 Uranus Avenue
Contact:

Re: Fucking Tactics, How Do They Work?

Postby Thad » Tue May 27, 2014 8:51 pm

Hm -- Tiled Map Editor looks promising.

User avatar
Thad
Posts: 13165
Joined: Tue Jan 21, 2014 10:05 am
Location: 1611 Uranus Avenue
Contact:

Re: Fucking Tactics, How Do They Work?

Postby Thad » Sun Nov 30, 2014 2:43 pm

I figure I should at least start looking over toolkits and shit while I'm out of work.

As far as open-source multiplatform toolkits, Haxe/OpenFL seem like popular choices (Papers, Please and Evoland both use them). I've sort of got a knee-jerk aversion to anything that says "Flash" on it, but that's probably unfair given that this is an open-source toolkit explicitly designed NOT to have the usual limitations of Adobe Flash.

Mozilla recently had a competition called GameOn for people to build browser-based games using its toolkit. That probably bears looking into. It references a site called Build New Games, which also focuses on HTML5 game development. It hasn't been updated in a year and a half but it's probably still a good overview.

User avatar
zaratustra
Posts: 1665
Joined: Mon Jan 20, 2014 6:45 pm

Re: Fucking Tactics, How Do They Work?

Postby zaratustra » Sun Nov 30, 2014 5:00 pm

unityyyyyyyyyy

User avatar
Thad
Posts: 13165
Joined: Tue Jan 21, 2014 10:05 am
Location: 1611 Uranus Avenue
Contact:

Re: Fucking Tactics, How Do They Work?

Postby Thad » Sun Nov 30, 2014 8:26 pm

Unity's certainly the popular choice right now and probably the easiest route to go, but given that my ultimate goal on something like this is to make it as modifiable as possible, I'm more interested in finding something open-source so that every tool in the chain is free-as-in-speech.

Who is online

Users browsing this forum: No registered users and 6 guests