Interview The Fall Q&A at No Mutants Allowed

[simmschn]

ok, so I kinda skipped most of the thread
but shimsinshsisnsn
whatever the fuck your name is

Oh, it's not my name. I used a random name generator and took the craziest result.
Why? It is fun when people try to quote me with this nick. :D
So, Wyrmy Boy, try to amuse me a bit more.

you are quite the idiot
look at the greatest difference between TB and RT

You said "quite"?! That means that there is still hope for me? I am somewhat relieved.

in TB you always have some type of system that has Action Points, which determine just HOW MUCH you can do during in a turn

Of course, but you have the same "points" in RT, too. In RT the amount of your actions you can do in a certain amount of time is limited by the time itself. So, it is absolutly correct to say that the action points of TB combat in one turn are the number of seconds in RT in one "turn". The basic concepts is the same. Action points are necessary for TB combat, but they do not define it.

in RT, how much you can do is determined on how fast your character moves
so if your character's gun animation is faster than the enemy's, he will shoot faster
so speed is based on animation, rather than actual speed like it is in a TB system

Yes, that's true. But the animations play only a little role. Today RT games have their own in-game time, old games didn't have it. In these games the animation created the timing, you can only play these games with moslo on modern computers.
Far more important is the player's skill: some teenies are quicker in handling the interface, so they have a big adventage, because they can do more actions in a certain amount of time (turn). TB combat is a bit fairer, because really everyone has the same limitations.

damn you're stupid
go download the stfu bible

I would love to, but I really haven't any clue what you are talking about.

and if you think Phase Based = Turn Based you are SERIOUSLY wrong

Yes, what a nice suggestion. The people here can not give me a really good explanation of the difference of TB-combat and RT-combat with autobase after each turn. And now you want to introduce "phase based" combat, which lies something in between. We should keep these concepts for the advanced course next summer.

 

[EEVIAC]

I can understand how rounds can be mistaken for turns (not really,) so perhaps turn-based just needs to be issued with a more descriptive nomenclature. I propose Seperate Sequential Turns Based On Initiative. Any ammendments welcome.

 

[Rosh]

Of course, but you have the same "points" in RT, too. In RT the amount of your actions you can do in a certain amount of time is limited by the time itself. So, it is absolutly correct to say that the action points of TB combat in one turn are the number of seconds in RT in one "turn". The basic concepts is the same. Action points are necessary for TB combat, but they do not define it.

Yes, they do, moron. They determine your movement and actions, whereas in RT your movement and actions are calculated a much different way.

Movement and actions are very different in RT versus TB. If, by now, you don't know how the difference in movement is, then just hop the fuck out of the discussion as you don't have the knowledge required to keep up with the conversaion.

A good example of the difference between RT and TB would be the later Might and Magic games, especially 7 and 8. Notice how both modes of combat play very differently, causing exploits in some places and to go against an enemy who wields a long-range weapon in TB is just insane thanks to the kludging they had to do in order to put both in together. Yet, there will be the problem of firing long range weapons and spells on moving enemies, often making them miss almost all the time.

Now, if they were the same, do you think it would be so hard to balance both of them out together? Of course not, because the mechanics are quite different on a base level.

Yes, that's true. But the animations play only a little role. Today RT games have their own in-game time, old games didn't have it. In these games the animation created the timing, you can only play these games with moslo on modern computers.

Wow...just...wow... Whenever I think you've made an uneducated statement, here you go with another whopper to cover the rest. Simply amazing. Saint has a few good examples already written out that have been pretty much as stock filler posts to explain it to the uneducated people like yourself. Yes, we tire of no clue idiots coming in an blathering whatever they wish to rape upon their keyboard.

It's simply tragic.

 

[Otaku_Hanzo]

Wasteland is a good example of phase based, but try to imagine that game with as complex situations as Fallout had.

Well, per the definition of PB given in Section8's article, I really can't say that Wasteland was PB. Like Rosh said, it was more TB but you gave commands to everybody all at once. Kinda like the old Bard's Tale games and other dungeon crawlers of that ilk. If those games are truly considered PB, then hell yeah I've played plenty of PB games in my life. I was just curious what was considered to be PB as I never really thought about it in terms like he gave in the article. It's always either been RT or TB for me.

Hmmm... I wonder if I can fit PB in here one more time. Oh, wait.... I just did.

 

[simmschn]

Yes, that's true. But the animations play only a little role. Today RT games have their own in-game time, old games didn't have it. In these games the animation created the timing, you can only play these games with moslo on modern computers.

Wow...just...wow... Whenever I think you've made an uneducated statement, here you go with another whopper to cover the rest. Simply amazing. Saint has a few good examples already written out that have been pretty much as stock filler posts to explain it to the uneducated people like yourself. Yes, we tire of no clue idiots coming in an blathering whatever they wish to rape upon their keyboard.

It's simply tragic.

Tragic is that you know nothing about programming. But RPGCodex is not a computer science forum, so that knowledge is not required for you.

I make it very easy for you: Get a copy of "Wing Commander 1" or "C&C1" and try to play it on your new computer. You will see, both games run too fast. That's because the developers couldn't imagine that computer would get so fast. They didn't implement a speed check, the implementation of the engine (you called it animations) determined the speed.

A few years later programmers changed their methods, I will try to show it.
pseudo-code for games :

InitGame(); //initalize game
while (Message != QUIT) // game loop
{
startTime = GetTime();

while (PeekMessage(Message)}
{
TranslateMessage(Message);
DispatchMessage(Message);
}

MoveGame(time); // movements
RenderGame(time); // display

// calculation of end time
endTime = GetTime();

time = endTime - startTime;
}

The trick is in the MoveGame() function:
MoveGame(time)
{
if (key=LEFT) Position.x -= time * 100;
if (key=RIGHT) Position.x += time * 100;
}

That's how it works in its most basic way. The variable "time" and the movement formulas create a in-game-time based on your hardware. Rosh, if you have further questions, feel free to ask. But it would be advisable to send me a private message, because I think it's not on topic and it would be very boring for most people here.

 

[Rosh]

[snip a whole load of irrelevent bullshit]

Try to keep on the topic, stupid. Enough of your pathetic straw men arguments.

In other words and to make it simple for your moronic little mind to digest easily, animations and animation time both play a big part when considered for timing, else they look like shit. It is another factor, a BIG one when considering RT, that you just didn't clue in on. Good, you know how to program a bit. So can I, and I know the importance of coding my own internal clock for a game. I believe I have mentioned that here somewhere before on this very site. I also have been in and around the industry for almost two decades. You've demonstrated yet again that you know jack shit and are perniciously bullshitting your way through another astounding waste of bandwidth.

Please don't pull out the "second language" bullshit as an excuse again (or however many languages). Take a fucking number.

 

[simmschn]

Take a fucking number.

@Rosh:
Then I take number 55, I always liked it.

By the way, animations are only are problem for modern games on modern PCs, old games on modern PCs have no problems with their old animations. When you play an older game on your modern hyper-PC the game is artificially slowed down, because there are not enough animations/AI/path-finding/... needs for your CPU.
And I really do not see what this simple fact has to do with TB and RT combat. So please stop talking about your animination limitations. The problem was solved long ago.

 

[Rosh]

By the way, animations are only are problem for modern games on modern PCs, old games on modern PCs have no problems with their old animations. When you play an older game on your modern hyper-PC the game is artificially slowed down, because there are not enough animations/AI/path-finding/... needs for your CPU.
And I really do not see what this simple fact has to do with TB and RT combat. So please stop talking about your animination limitations. The problem was solved long ago.

You know, I was about to hand this off to someone else as your complete idiocy has gotten to depths I hardly dare to touch.

What I am talking about and what you really have no clue about, is synchronizing the animations to go with the attacks or other animation. This adds on top of movement time and movement animations, affecting how the character system works, often in both directions. All this has to be timed just right to avoid it from seeming very clunky in an RT base. In TB, this isn't an issue at all.

So please share with us your next failed attempt to talk about something you demonstrably know little to nothing about.

 

[simmschn]

But that isn't a problem fo RT games at all. Only in a very bad programmed engine this synchronization would be a problem. For example: The damage of an attack is not affected by the fight-animations in most games. Perhaps it can play some role in games like Mortal Kombat but for most games I know that's not a problem.
In a RTS game it can be possible that a tank has to stop before it can shoot (bad example, I know). So it has to stop its movement animation and start a firing animation and during that time the enemy can be out of range. But that's not a problem of RT combat, that's just realistic. In TB the enemy cannot flee so easily, but that has nothing to do with "animation synchronisation", that's just how TB and RT combat work.

 

[Section8]

Phase-based is pretty much a misnomer if you look at the mechanics right. It's really just RT in a slightly different format that puts it into a little more orderly fashion.

True, but I really dig the concept of phase based where the resolution is precalculated rather than done on the fly. Potentially, a well done phase based combat system could do cinematography like a motherfucker. It would have so much visceral appeal you wouldn't need to worry too much about traditional eye candy.

Of course, but you have the same "points" in RT, too. In RT the amount of your actions you can do in a certain amount of time is limited by the time itself. So, it is absolutly correct to say that the action points of TB combat in one turn are the number of seconds in RT in one "turn". The basic concepts is the same. Action points are necessary for TB combat, but they do not define it.

This is quite true, but the issue with it is the fact that you no longer have a simple variable to tweak, you have a whole load of content between artists and designers, ie a whole lot of additional complexity that isn't really necessary.

To me that is the true beauty of turn-based. It's an abstraction, so the actions available to the player are not limited by a need to provide accurate visuals. For example, a player can shoot on the run or from behind cover because the actions involved are performed sequentially. It's elegant simplicity. And as anyone who has ever enjoyed a book can attest to, not everything needs to be blindingly visceral.

 

[Psilon]

Simmschn, thanks for showing us that you've looked at a DirectX demo before. Your mastery of calling TranslateMessage() before DispatchMessage() is truly astounding, though 'key=LEFT' is going to seriously screw with the game logic. If you're going to dump a zillion API calls that apply only to Win32 C programming on us and mean absolutely nothing in a "pseudocode" example, at least bother to proofread your code and get the braces right.

However, you're full of shit on the "old games didn't do speed checks" idea. Ever play something like Jazz Jackrabbit 1 and get a "Runtime error 200" message? That's precisely because of the speed check. Anything linking in with the Borland CRT library (mainly Turbo Pascal) doesn't work on fast machines. That's because it runs a loop and measures the time it takes to execute. Unfortunately, the timer's granularity is too large for modern machines, and so the loop takes "zero" time. Dividing to figure out instructions per second causes the division-by-zero error, code 200. There are numerous DirectX games that don't limit the frame rate; look at the Win95 versions of Red Alert and Master of Orion 2.

Oh, and by the way, no one actually uses TranslateMessage() for games. Every DirectX game I've seen uses DirectInput--which doesn't look at keyboard events at all--or bases keyboard input off the WM_KEYDOWN and WM_KEYUP messages. Nothing bothers with TranslateMessage()'s WM_CHAR and WM_DEADCHAR, because they don't fire until the key's released. Would you want to play Breakout by pressing the arrow key every single time you want to move 10 pixels to the left?

So yeah, this isn't a CS forum. That doesn't mean you can get away with vacuous, half-accurate statements about coding.

 

[Diogo Ribeiro]

Psilon has displayed yet another reason why i love this place

 

[Rosh]

But that isn't a problem fo RT games at all. Only in a very bad programmed engine this synchronization would be a problem. For example: The damage of an attack is not affected by the fight-animations in most games. Perhaps it can play some role in games like Mortal Kombat but for most games I know that's not a problem.

Holy shit. Clue Rating: 0%

In a RTS game it can be possible that a tank has to stop before it can shoot (bad example, I know). So it has to stop its movement animation and start a firing animation and during that time the enemy can be out of range. But that's not a problem of RT combat, that's just realistic.

Nor is...say moving until it takes half of a round, leading to being stuck there and unable to attack until the next "round"? That is an IE example. For a Diablo example, it really doesn't take much imagination to see what a desynch would result in there. As Gareth has pointed out, there is a strong relationship between the coders and the artists...well, not relationship, sometimes piss vinegar angry at each other sometimes. And yes, I can vouch that he has been in the industry. Something that you, SimMoron, can only claim that you played a few games and whack off your keyboard like an inbred chimp on crack.

In TB the enemy cannot flee so easily, but that has nothing to do with "animation synchronisation", that's just how TB and RT combat work.

Exactly, as in being DIFFERENT in that regard. Is the last three pages starting to absorb into that intelligence sink installed in your cranium?

Psilon: Holy shit! :shock: That brought a tear to my eye. It was beautiful.

 

[Saint_Proverbius]

By the way, I read some time ago, that the combat in Fallout 1 was real-time at first and then they implemented a forced auto-pause after each round and then they had their turn-based combat.

Most incredible pile of bullshit. Ever.

I remember that they first implemented real-time combat (with your hexes), but of course they planned to make TB combat from the beginning. Real-time combat was just their first step to implement turn-based combat. Is it so hard to understand?
Today games often feature real-time and turn-based combat, so this method will be used more often. Even the Fallout 3 developers first made the real-time combat, they just started a few weeks ago with turn-based combat. This is the natural way! You should inform yourself a little better. All the important developers are now posting at certain forums.

Fallout was never, ever real time combat.. Ever. Either the boys over at BIS were lying to save face or they were mistaken about it, because the lead programmer(i.e. the guy who would have had to impliment such a thing or see to it that it was implimented) on Fallout says it never was. Fallout was turn based because GURPS was turn based, the same reason the hexes are in there as well.

 

[MetalWyrm]

OK simmschn
maybe I can explain this to even your tiny little mind:

take this hypoethical example (and I know this has happened in BG2 many times, and yes, Baldurs Gate is a fairly NEW game, so don't pin that "old games ran too fast/slow")

Ok, so... my character, has really high agility let's say, and in a TB system, would only take 2 APs to hit the character
however, his animation is involved with a broadsword
and the broadsword animation is long

now, the character he is going against, has low agility and would take many points in TB to swing his dagger, but, because the dagger animation is very short as opposed to the broadsword animation, he can swing faster in RT

now here's how the combat goes in RT
P w/ Broadsword takes 5 seconds to swing
P w/ dagger takes 2 seconds

if you calculate over the period of 10 seconds, the player with the broadsword took two swings and player with the dagger took 5
why? because of the frames of animation it takes

this may be somewhat exaggerated, but it illustrates the point better

now let's look at this situation in TB
for player w/ broadsword, it takes 2 APs to swing said Broadsword
for player w/ dagger, it takes 5 APs to swing said Dagger
and this is all due to the agility I said they had earlier
let's say both players have 10 APs

here's the combat situation:
Player w/ broadsword swings 5 times in one turn, even though his frames of animation for the broadsword are lenghty, it doesn't matter becuse the Action Points determine how fast he is, not animation
while player w/ dagger only swings twice

conclusion:
Turn Based system justifies the character's speed, and not the character's weapon

ps, if you've ever played diablo, and gotten a weapon of haste, you will notice that the animation is sped up, or amount of frames used in the animation are slower
that is the only way you can make a weapon faster in RT that I know of
however, that is only the weapon being modified, and not the character

 

[MetalWyrm]

Simmschn, thanks for showing us that you've looked at a DirectX demo before. Your mastery of calling TranslateMessage() before DispatchMessage() is truly astounding, though 'key=LEFT' is going to seriously screw with the game logic. If you're going to dump a zillion API calls that apply only to Win32 C programming on us and mean absolutely nothing in a "pseudocode" example, at least bother to proofread your code and get the braces right.

However, you're full of shit on the "old games didn't do speed checks" idea. Ever play something like Jazz Jackrabbit 1 and get a "Runtime error 200" message? That's precisely because of the speed check. Anything linking in with the Borland CRT library (mainly Turbo Pascal) doesn't work on fast machines. That's because it runs a loop and measures the time it takes to execute. Unfortunately, the timer's granularity is too large for modern machines, and so the loop takes "zero" time. Dividing to figure out instructions per second causes the division-by-zero error, code 200. There are numerous DirectX games that don't limit the frame rate; look at the Win95 versions of Red Alert and Master of Orion 2.

Oh, and by the way, no one actually uses TranslateMessage() for games. Every DirectX game I've seen uses DirectInput--which doesn't look at keyboard events at all--or bases keyboard input off the WM_KEYDOWN and WM_KEYUP messages. Nothing bothers with TranslateMessage()'s WM_CHAR and WM_DEADCHAR, because they don't fire until the key's released. Would you want to play Breakout by pressing the arrow key every single time you want to move 10 pixels to the left?

So yeah, this isn't a CS forum. That doesn't mean you can get away with vacuous, half-accurate statements about coding.

I recall that simm said something about C&C 1 running super fast on computers
and it does
but that's the entire game running fast
becuse Westwood seems to make their games in a very weird fashion
however that doesn't mean that a unit goes faster than they normally would
ALL UNITS go faster on a faster computer
it's just the way that Westwood has made their C&C games
if you ever play something like Tiberian Sun on a slow computer, it will run slow
if you turn up the game speed, ALL UNITS go faster
so, take for example
you are running a 166mhz shitbox, and trying to run tiberian sun on the highest possible speed
however, the game runs slowly
now, run the same game on a 466, or a 1ghz, on the highest possible gamespeed
and it will run fast as fuck
that's the way Westwood made those series
so don't mix it up with cRPGs thank you