MMXI said:
No. Increasing the depth of a single character only means increasing the selection of possible actions and not allowing them to do things simultaneously when you have a party to allow for simultaneous actions. If you don't have a party to allow for simultaneous actions then the only way you can get that sort of depth is to allow a single character to do so. You are treating the benefits of multiple characters in a very traditional way. If you claim that single character combat cannot be tactical then why are you dismissing ideas that would result in the addition of party advantages to single character gameplay?
I do? (Hint: no.)
First, tactics doesn't have to mean parallelism, increased depth may very well involve complicated sequences of actions both during and before battle. The problem is that as long as we stay in the concrete realm where men are men, women are women and little, hideous, green goblinoids are little, hideous, green goblinoids, rather than going out to elegant and abstract kingdoms of games like Go, the main purpose of TB is to allow single person with single input interface and single focus of attention to perform parallel actions serially.
Second, yeah, I treat my characters in a very traditional way, for example, I'm very attached to the idea of a character representing a person with limited number of limbs, single head and some sort of physical integrity. It would take some serious persuasion to make me warm up to the idea of having my character attack several different targets with an array of sextuple-wielded weapons while also casting two different spells and hiding in shadows for successful backstab. Even more so if my character would also send one of his legs forth to scout out the enemy while arranging his remaining leg and greater-than-usual number of arms in an ambush formation.
Some things just don't translate well from single character to party and vice-versa. Party achieves extra depth by being able to perform concerted, pretty much simultaneous actions. Single character can achieve extra depth by increasing complexity of individual actions and polling rate at which the game asks player for input. However 'continuous' is pretty much max polling a game can achieve so TB doesn't benefit a single character much.
You can 'artificially' increase this rate by introducing bullet time and map a unit of game time onto a much longer stretch of real time, but then you hit the molasses, and it doesn't really matter if we are speaking of really short turns or actual, continuous bullet time.
But you can do this for party based games too. RTSs are real-time after all and I'm sure you can micromanage hundreds of units if you are good enough. Oh, but you'll just mention that each individual unit in an RTS has far less depth than in an RPG. Of course, you are correct. But then my argument holds up that if you introduce a significantly greater amount of depth to a single character RPG then it could very well benefit more from being turn-based.
It doesn't. Whatever depth you introduce to a single character can be handled in continuous time by the player, since he doesn't have to share time between characters. In RTS player can also act either in continuous time by giving identical simple orders to masses of units simultaneously, or in quasi continuous time by alternating between units very quickly and giving them orders that are still of very limited depth.
In a party based RPG player has to alternate between characters and give them complex, synchronized orders. Turns just make the syncing automated, saving player a lot of routine, but still hectic input.
Do note, that most of single-character RT RPGs do pause for inventory or spell management, it's just that they don't need automation of syncing on cycling since they don't have either.
Also, do note that TB still works better for single character in indirect, point-n-click mode - I have already mentioned that I favour RT for FPP (or TPP) RPGs involving single character, though I generally also favour FPP in all RPGs.
Wait, you merely mentioned how long it takes you to physically switch to a particular spell, not how long it would take to assess which spell would be the best to cast out of 100 or so that are available.
Because once you learn the system by heart, and keep a 'cache' of plan variants in your head, decision making takes much shorter than actual action of physically switching between items or spells.
In real-time games I tend not to use highly situational spells when the time comes for them to be useful because I'm not used to thinking about using them. If a spell has about 10 uses throughout a game then I'm just not used to thinking about it in the heat of the moment
Because you shouldn't. What you should do is see opportunities for each of those spells as they appear as the situation evolves.
How often in, say, Wizardry 8, do you not have most of your next turn thought through (in form of alternative variants) by the time you are allowed to give orders?
Well, consistency of mechanics is a fundamental part of the game already. These issues just need to work on top of it. Having a consistent method of control in both combat and non-combat gameplay is important for unifying the mechanics, in my opinion.
I think that control is mostly superficial, but unified controls are, of course, good.
The main problem with mechanical consistency can be formulated as:
"If I was an NPC, could I infer by just observing the gameworld phenomena that combat is taking place?"
For example, if a character can perform a series of actions (like exit cover, shoot, reload and return to cover) without anyone being able to react in any way, I know I'm in the middle of TB combat.
The problem with TB in general is that serialization of normally parallel actions can serialize things that really should have remained parallel. There are things like reaction shots and such that fix such problems but they are generally band-aid solutions, they apply extra, corrective mechanics aiming for canceling unintended side effects of original, rather than actually fixing the original.
Another example - in a typical AP system we have a character with 8 AP/turn and one with 10AP/turn. Both have 10mm pistols they can shoot for 5AP. The second character is by 1.25x faster than the first but can shoot twice as often due to the first doing those weird, 3/8 turn pauses between the shots. This is a timing artefact introduced by the TB system.
If you're aiming for unified, consistent mechanics, there should be no artefacts of TB combat that would be perceptible to characters in game. Everything should happen the same way no matter when, in regards to the steady ticking of the turn timer it occurs, and no matter if it occurs in combat or not.
Incidentally then you will also have a 100% exploit proof RT/TB switch.
Yes, which I can't have in a strict sense because turn-based exploration of a friendly town with a large party will destroy the game entirely.
Luckily exploration rarely calls for fast, synchronized actions on part of the party. That's why it tends to be RT even in TB games.
:]
Strange. When I say synchronous turns I mean that characters take their turns at the same time. Their turns happen together, in unison. They start at the same time and end at the same time. The game ticks by the time units, allowing an enemy to shoot you as your character moves.
In Fallout you can spend one time unit moving out from behind cover, shooting with most of the remaining time units, and then popping back behind cover with the final one. The enemy can then do the same to you. Games like X-COM had reaction fire to allow opposing units to perform actions in each others turns. In other words, in both games, the situation at the beginning of each character's turn would not be the same.
When I say synchronous turns I mean that all characters move together. If you tell your character to move 10 units north and the AI tells an enemy character to move 15 units south, both units will move simultaneously until the game pauses to allow the player to choose what to do next.
And that's what I mean by simultaneous. "Synchronous" merely refers to characters' turns corresponding to each other - n-th turn for each character will correspond to n-th turn for every other character. They may be simultaneous or shifted, but the important thing is that a character will only have their n+1-th turn when all the other characters finished their n-th turn - the turns will never fall out of sync.
I'll assume that your first usage of "TB" means turn-based, while your second usage of "TB" means tile-based.
A fuck-up on my part, but yeah, you've got the meaning of what I *tried* to say, rather than what I said.
There are two groups of reasons why I want things tiled.
The first is that, for a development team consisting of a single computer scientist, content creation needs to be incredibly easy in order to be quick.
That's ok, but doesn't really explain relation between tiles and the mechanics. It also doesn't explain submission to the tile based philosophy rather than it's conditional acceptance with ability to violate it at whim (like in Morrowind where you construct interiors out of tile-like blocks that require strict, tile-like placement, but also have multitude of objects and features that can be placed arbitrarily).
Another part of the vision is to have the same granularity of simulation across the entire world, regardless of where the player is located. I don't want the game to run complex AI and physical simulation around the player, but crude estimates to play catch up when the player moves into a new location. If the game's simulation can cause one character to steal from another character when in the player's view, it should also be capable of performing the same simulation 10 miles away from the player's view.
I don't think it's a good approach. While depicting in-game reality close to the player requires detailed and involved mechanics, there is no reason for substituting this mechanics for much coarser statistical approximation when the player is out of range, as long as it gives the same results when player isn't there to interfere. The player won't observe it directly anyway, and you will free yourself of limits of keeping everything in memory. More detail far away means less detail close-by.
I'd rather generate everything I can get away from seeds on the fly (constant seeds if in need of persistency), possibly generate alterations to this persistent world as well, using random seeds and some rule-system and only trace individual things and characters when necessary. Each chaotic or non-deterministic system, no matter how complex, has certain probabilities of future states. Future state can therefore be determined just as well by weighted random selection as it can be by meticulous simulation. The only difference is whether someone is looking so it benefits the developer and ultimately the player if you simulate up close but estimate far away.
Also, to help things out, most gameworlds are also stable, steady-state systems.
The second reason is, as I mentioned before, I want the player to be able to work out precisely how possible actions will affect their characters, while making differences in things like positioning highly noticeable.
Doesn't introduction of any randomization already invalidate that?
Let's say the surface of the game world is broken up into tiles of grass, mud, rock, sand, snow and swamp. If each of those surfaces have different effects on the character standing on them, then the player can make use of the layout of the land around his characters to benefit him tactically in, say, a battle. However, if you could stand between the tiles then a character could be standing on 25% sand, 25% rock, 25% swamp and 25% grass. If that character moves a pixel the ratio will change slightly. In my mind that would make the simulation less meaningful on a tactical level, as well as allow for a greater ease of AI abuse.
You can weight it for fuzzy transitions, randomize for patchy transitions or use selected point for sharp ones - what's there not to like?
Well, you have to consider that if I make a doorway into a room 2 "blocks" wide, and each character is 1 "block" wide, the player can easily position two characters next to each other in the doorway with a very small amount of path-finding issues, issues that would be both annoying and expensive to solve if I had pixel perfect collision of objects over continuous space. I do not see a grid as a huge limitation for a party based game with a high degree of tactics involved.
I'm not well versed in AI algorithms (alas), but from player's PoV there is little difference between 2 characters wide doorway and any doorway noticeably smaller than 3 characters.
Yeah, that's awesome for a first person or over the shoulder perspective real-time game. You can shimmy a little closer into the shadows if an enemy is starting to suspect your presence.
Well, Deus Ex was rather forgiving in this regard (way too forgiving, in fact), but you could assess the level of lighting pretty accurately by just looking at the shadows.
It's not really about that with a single character. What I was getting at is that in a game like X-COM, you target a position that an alien is standing in and you shoot at it. The game can calculate whether you hit or not and how much damage you've done. If you miss, the game works out where your projectile went, destroying pieces of the terrain and structures such as walls. If the game has simultaneous turns, you target the alien and it could have moved by the time you get the shot off. If you target actual enemies rather than positions they are standing in, this would allow an alien to move back behind a wall before you get your shot off, making the game more about the player's prediction of what the AI will do next as opposed to sitting down, assessing the situation, then performing an appropriate action like in true turn-based games.
You can have AI lead the target. You can switch between manual aiming and AI aiming. You can add indicators of various sorts. And finally, you can remember that your projectiles are generally very fast compared to the characters, so unless you're firing some sort of long range artillery, you don't need very complicated predictions to hit the target, so the AI leading will usually do just fine, especially with AoE weapons. If your projectiles are bizarrely slow for some reason, then it's a fact of life that you will often miss when the target makes unexpected move.
And you will have TB or PB to help you make your assessments too!
The real issue is with actions that take a long time to perform. Let's say the player tells their character to load up a mortar and fire at a particular location, hoping to hit the 5 enemies currently standing there. By the time the mortar hits the 5 enemies could have dispersed.
But that's the part of the fun with mortars and indirect fire weapons in general.
It's not even easy for me to explain why it wouldn't work nicely, and I know my game and vision better than anyone.
Hard explanations are always the most fruitful ones. Either way and to both sides.
I agree. It is a very good idea. It just wouldn't work in my game. You see, the main benefit of your idea, in my view, is that you can then switch to a continuous time scale while keeping the same (lack of) reliance on player skill as a standard turn-based game. This would allow you to bring across many of the benefits of a turn-based game to real-time, allowing you to play a party based game without discrete time chunks. I'd love to implement something like that, and I've thought about doing it in the past, but the necessity of using what is effectively a block based world destroys its benefits.
And that's part of the reason why I despise blocks.
Would be good for an action RPG, yeah. Though I really don't consider it that important.
I thought you liked unification of action and presentation as well as unified mechanics?
How about that:
In most games there are many hidden assumptions burried in the mechanics. Those hidden assumptions are often not thought through (and often impossible to think through fully), asspulled (since relevant RL statistics may not even exist) and generally limiting (in a way any soup of explicit, pre-digested mechanics will be).
The benefit of using less abstract mechanics is that rather than a set of explicit, possibly inconsistent or nonsensical assumptions you will get a much more flexible set of implicit, sensible and internally consistent ones - at the expense of being computationally intensive.
You don't need to wonder how much does a visor in your helm compromise protection against arrows and asspull such data if you can check for collision with helmet. You don't need to wonder how to limit usefulness of a dagger against some giant creature if short length of such weapon won't permit it to hit a (coarse) vital organ hitbox inside the model.
Since most games use things like physics engine and complex collision for purely cosmetic purposes, why not use them for mechanics instead?
DraQ said:
Compared to Diablo no (and it isn't RPG anyway), but compared to Daggerfall? Are you kidding? In what way did BG not lower the bar apart from having nice narrator and somewhat discernible characters?
Combat? Party? Items? Encounters?
World mechanics? Chargen? Item-maker? Freedom?
The only problems I ever experience with the path-finding was outside of combat. For example, when telling all your characters to move to the the side of the screen after clearing out a dungeon level, or telling your characters to all move through a door at the same time. But in combat? Path-finding never, ever affected my ability to direct a battle. Perhaps it's the difference between our play styles? That would make sense considering you accused the game of playing like a mini RTS. When I run into combat the game automatically pauses. I then select my first character, tell it to do something, select the second character, tell it to do something, select the third character etc. I then unpause the game and watch the outcome.
Which almost invariably ends up being "character #3 bumps into the backs of #1 and #2, then wanders off in search for adventure, failing to comprehend that the obstruction is momentary" whenever the combat is happening in the interiors.
And you hardly have to go through any of the generic wilderness zones to win the game.
But then I don't get all the cool stuff.
And the black unexplored areas will taunt me in my dreams. D:
Putting in square miles of generic 'lolforest', then hiding a powerful item under a clump of pixel in the far corner of the map is just plain old trolling.
Cool. Daggerfall's combat made me ragequit. Oh, wait, it didn't, even though it was far, far worse.
Well, it might have been worse, but it wasn't nearly as infuriating. Dumb AI is easier to stomach when it belongs to the enemy, even if it cripples combat gameplay all the same.
And you've conveniently missed out my Planescape: Torment example where I explain exactly why a game with some stand out elements may not be more fun to play than a game that is solid all round.
But PS:T was a blast. Combat sucked, but not nearly hard enough to stop me, even if it was an order of magnitude more abundant.
By the way, do you hate Betrayal at Krondor by any chance?
Still on my 'to play list'. Actually I'm quite pumped due to many awesome things I've heard about the mechanics.
I'm relative newfag, TBH, I moved from c64 to PC about the time when Terra Nova hit the shelves. I've been mostly working my way backwards retroactively.
