Real Time with Paws - what's wrong?

[Virtz]

Look at Brigade E5 or recent 7.62.
It might be lacking in certain areas like leet graphix or be a bit buggy around the edges, but it's RTwP done RIGHT.

As far as Brigade E5 is concerned, in wilderness areas it pretty much played like any other RTwP game with guns (once you got a decent shotgun or rifle). That is, you could go on and win without loses using line formation like some Napoleonic era moron commander because the enemy would act no better and just charge at you Red Army style until they got into decent range to fire. Some would try to flank you, but all in the same fashion (without proper use of cover) and they'd just end up getting shot from a different angle.
This sort of AI worked fine for urban areas, although the impossible ods the game threw at me at times(I'm supposed to kill 15 people with a crappy pistol solo?) forced me to play cat and mouse and just have the enemies die from a blast from around a corner.
But either way, I've yet to see an AI that wouldn't act retarded (and used cover) in wilderness areas in a tactical RTwP game. The only RTwP game where I couldn't (effectively) use cheap tactics like line formation thus far was X-Com: Apocalypse, but that was mostly because the damn game couldn't keep up with the view calculations in real-time so I often had to deal with invisible enemies. But even if it was a bug, it kept my soldiers from acting like freaking robots that would all simultaneously fire at an enemy once it got into range.

 

[cardtrick]

Throwing in the issue of "pause" just confuses the issue. The pausing or lack thereof is irrelevant to the nature of the real-time implementation. All single player games expect to be able to be paused. Players get annoyed when their choices become "piss your pants" vs. "lose your entire party while you go to the bathroom". Multiplayer games, on the other hand, may or may not include a time-out functionality, but as the number of players grows larger, typically do not, for obvious reasons. Pausing is purely an accomodation to single-player gameplay, and has nothing to do with real-time vs. turn-based. If there were multiple players, the pausing would be unnecessary and undesirable.

Although I agree with you broadly, I do think that you're oversimplifying things. What you say is perfectly true for a game in which the player controls only a single character -- there is absolutely no real gameplay difference between RT and RTwP.

However, if the player controls a party then there is a real distinction. RTwP allows the player to give orders to several characters simultaneously, while RT in practice limits the player to performing only one action at a time. This has important gameplay consequences and cannot be brushed aside as an "accommodation to single-player gameplay."

Anyway, my point is just that I do think RTwP is a meaningful term. I don't believe it to be the abomination that some in this thread do, but I have never played an RPG in which it was done well (with the exception of The Witcher, which doesn't really count because it's a single-character game). The main problem with RTwP as it is commonly implemented is that it distances the player from the combat and makes it a less engaging experience, but I don't think that this is an inherent property of the system. Rather, it's the fault of lazy developers.

 

[Section8]

Throwing in the issue of "pause" just confuses the issue. The pausing or lack thereof is irrelevant to the nature of the real-time implementation. All single player games expect to be able to be paused. Players get annoyed when their choices become "piss your pants" vs. "lose your entire party while you go to the bathroom".

That's clearly not what we're talking about when we talk about pausing in this instance. There's a massive difference between hitting escape to bring up the main menu and pause the gamestate while you take a piss and a game that relies on being able to pause the game and micromanage party orders just to be playable.

Multiplayer games, on the other hand, may or may not include a time-out functionality, but as the number of players grows larger, typically do not, for obvious reasons. Pausing is purely an accomodation to single-player gameplay, and has nothing to do with real-time vs. turn-based. If there were multiple players, the pausing would be unnecessary and undesirable.

Pausing is still necessary in a multiplayer game where any one player is expected to control more entities than they can reasonably handle in real time. The solution is - don't give the player more than a human can handle. The same question ought to be asked of a single player game too - is it necessary or desirable to have the player constantly pause the game?

And that's what we're driving at here - when the pause becomes a necessary facet of gameplay it can't be disregarded as a non-issue. The difference is crucial - just like if you put a hard limit of 5 seconds per turn in a system like Fallout - it ceases to play in the same way, because the player is forced to act quickly and impulsively. Adding a pause to a real-time system works the opposite way - it removes the time pressure, which is usually the cornerstone of the challenge, and though it isn't inherent to the system, most developers fail to adequately compensate for this lost challenge and you get games that play themselves while you watch, like Dungeon Siege or KOTOR.

Actually, that's exactly the RIGHT way to do it. The CORRECT method of producing a real-time game *IS* to time all actions and create a true asynchronous real-time game.

You misunderstand me. Probably my fault. What I'm saying is that you can't take a game system that expects six players, each controlling a single character, to function the same way as the same system with one player controlling six characters and the ability to pause the game at will. You end up with two fundamentally different games.

At the end of the day, I have no real prejudice against real-time games, though I think turn-based (or like) systems better lend themselves to games focusing on character skill. However, as soon you have a system that tries to float somewhere between turn-based and real-time, then you have to ensure you're preserving the advantages and disadvantages either end of the "spectrum" offers, and designers need to be far more diligent when working with any system that comes complete with its own crutch.