Maximum Football???

[sachmo71]

Originally Posted by spcd

Often, that includes a legion of passionate defenders of the game, see MOO3 for example

I still play this game. :angry:

[Eaglesfan27]

Originally Posted by vtbub

Please post here more often spcd. Intelligent debate is very fun to read.

I agree. Welcome to the board, spcd.

[JonInMiddleGA]

Originally Posted by spcd

but the game is just bad, not necessarily buggy, and it's the design flaws which will kill it

While we do disagree on a number of conclusions, I might just nominate this as the definitive comment about MF in the entire thread. If it isn't THE quote, it's pretty darned close IMO.

[st.cronin]

Originally Posted by rkmsuf

I feel like this thread needs some spectacular finale or something. We are right about at the who cares anymore stage.

A futile and stupid gesture needs to be done on somebody's part.

go bruins

[Godzilla Blitz]

Originally Posted by spcd

...the game is just bad, not necessarily buggy, and it's the design flaws which will kill it, even if they release a patch every two days. There are just mind-boggling posts over there at the moment: the frigging frame-rate affects the engine...

I'd bet you're off on the buggy part of the equation. There are over three pages of reported problems with the game already, and I would think that sales of the game are quite low at this point. I bet the reason we're not seeing hordes of bug reports is simply due to the fact that not many people have the game, and many of them appear to be stuck getting the game to work properly in the first place.

But I do agree completely that the design decisions involved with the game are boggling as they unfold. The design decision to create a game where frame-rate impacts play results is simply baffling. The implications of this are too much to bear. There is discussion that 30-32 frames per second (fps) is ideal, and that things work fairly well at 20+fps. Below 20fps and the results are unstable. But even if there is, say, a 10% difference in pass completion rates between a 32fps computer and a 24fps computer, that completely screws up the reliability of playbooks to produce realistic game results.

The offshoot of this is that the play that I create that works well on my computer at 32fps might work differently on your computer running at 23fps? If this is true, I simply don't see how you can possibly create playbooks for multiple users with any certainty. Do you label your playbooks with a frame-rate precursor: West Coast Offense (25-28fps ok)? Then you buy a new video card and redo everything?

Maybe I'm wrong and the differences in results aren't that great, but even a 5% difference in results in a game like this is significant.

/shakes head in wonder

[rkmsuf]

Originally Posted by st.cronin

go bruins

lol

[wade moore]

I wondered about the frame rate thing...

What I couldn't figure out is if it caused a problem when the human is controlling the qb (reasonable) or the AI is controlling the qb (out and out strange by my understanding of things).

[albionmoonlight]

Originally Posted by JonInMiddleGA

While we do disagree on a number of conclusions, I might just nominate this as the definitive comment about MF in the entire thread. If it isn't THE quote, it's pretty darned close IMO.

I'll agree with Jon here. Even if this game worked perfectly as designed, I still would not want to play it. Part of that is just different strokes for different folks. I've never been able to get into FM, which most consider to be the best text sim in the world. That's because a futbol game will never appeal to me.

But some of these decisions, like the framerate decision, the database choice, the physics driven stats, seem like things to which any reasonable gamer would object.

Certainly, I have to suspect that, had Mr. Winters been more involved in seeking out and presenting his design ideas to an educated and critical audience--before he had reduced them to code, he may have made some choices differently. And that's a shame because it's a lost opportunity--kind of like being Irish and NOT naming your kid "Miles O'Smiles."

[KWhit]

If anyone who knows anything about game design can comment on why the frame rate might impact the gameplay, please do so. I find it very strange and haven't heard of any other games where FR would have the kind of impact that is suggested here.

It makes no sense to me. Is there a reason why it would need to be coded this way?

[Godzilla Blitz]

Originally Posted by KWhit

If anyone who knows anything about game design can comment on why the frame rate might impact the gameplay, please do so. I find it very strange and haven't heard of any other games where FR would have the kind of impact that is suggested here.

It makes no sense to me. Is there a reason why it would need to be coded this way?

I think it's not necessarily a direct "frame-rate impacts gameplay", but more that the physics engine determines the play results, but the intermediary step is that somehow the physics engine determines what happens on screen, and what happens on screen determines the play results. In all fairness, to say "There was a design decision to have frame-rates impact gameplay." is not accurate, but the end result of other design decisions results in the frame-rate affecting gameplay.

I might have this explanation all wrong though, and perhaps someone with more knowledge will step in a clear it up. It does seem clear that frame-rates impact play results in the game, though. The extent of the impact is unknown.

[Antmeister]

Originally Posted by wade moore

I wondered about the frame rate thing...

What I couldn't figure out is if it caused a problem when the human is controlling the qb (reasonable) or the AI is controlling the qb (out and out strange by my understanding of things).

That is another thing that pisses me off. It shouldn't affect the physics of the game either way. A slower frame rate should just make it more choppier, but not affect if the ball goes farther or if a player fields the ball. In other words, the physic of the game shoud not be affected at all.

[wade moore]

Originally Posted by Antmeister71

That is another thing that pisses me off. It shouldn't affect the physics of the game either way. A slower frame rate should just make it more choppier, but not affect if the ball goes farther or if a player fields the ball. In other words, the physic of the game shoud not be affected at all.

Right, but if a human is controlling the QB it could be a matter of bad timing, etc. because of the frame rate.. not that the physics are off, but because what you are seeing is not jiving with what you are hitting on your controller.

[Bee]

Just saw a thread where no one has seen a fumble yet. Do they have fumbles in Canada?

[Godzilla Blitz]

Originally Posted by wade moore

Right, but if a human is controlling the QB it could be a matter of bad timing, etc. because of the frame rate.. not that the physics are off, but because what you are seeing is not jiving with what you are hitting on your controller.

Ah...I see. This may make more sense. I may need to stand corrected on this, then.

[rkmsuf]

Originally Posted by Bee

Just saw a thread where no one has seen a fumble yet. Do they have fumbles in Canada?

I think they are called "whoopsies".

[st.cronin]

Originally Posted by Bee

Just saw a thread where no one has seen a fumble yet. Do they have fumbles in Canada?

I guess fumbles break the AI.

[gstelmack]

Originally Posted by KWhit

If anyone who knows anything about game design can comment on why the frame rate might impact the gameplay, please do so. I find it very strange and haven't heard of any other games where FR would have the kind of impact that is suggested here.

It makes no sense to me. Is there a reason why it would need to be coded this way?

Framerate can have an impact, but it should NEVER have a significant impact on the end result of the game. You make a conscious decision to go with a fixed-timestep sim/physics engine or a variable-rate one. With fixed timestep framerate has ZERO impact, but you have to handle interpolation between sim timesteps to keep the graphics moving. Variable-rate sims don't need interpolation, but the results can differ slightly. By "differ slightly" I mean the player may be a few inches off depending on framerate. But this should never be enough to mean that a ball wasn't caught, for example. It's just another factor to account for when writing the code.

That's a very simplified explanation. But framerate should not affect gameplay at all. It should affect visual quality, and its impact in a shooter can be noticable simply because a low framerate is annoying and difficult to control, but the results should not vary that much.

[KWhit]

Originally Posted by Antmeister71

That is another thing that pisses me off. It shouldn't affect the physics of the game either way. A slower frame rate should just make it more choppier, but not affect if the ball goes farther or if a player fields the ball. In other words, the physic of the game shoud not be affected at all.

I always assumed that in most (all?) games the game engine was what determine what happened in-game and the screen was just a delivery tool used to display that to the gamer. So in effect, what happens in-game happens no matter what the FR is, but your FR just determines how much of it you get to see. (Basically just as you describe in the post I quoted).

Am I wrong in my general thoughts on how game code works in general?

[cartman]

Originally Posted by Bee

Just saw a thread where no one has seen a fumble yet. Do they have fumbles in Canada?

There is a workaround. Anytime you think there is a fumble, simply keep taking a knee until the other team gets the ball.

[sabotai]

Originally Posted by KWhit

If anyone who knows anything about game design can comment on why the frame rate might impact the gameplay, please do so. I find it very strange and haven't heard of any other games where FR would have the kind of impact that is suggested here.

It makes no sense to me. Is there a reason why it would need to be coded this way?

I have not been following this issue, so my response is mearly just a general answer to this question for all games.

For one, frame rate would effect the game in that it slows down the game's response to input. The slower the frame rate, the slower the game receives input from the user and that in turn creates a slower handling of the input and on screen respresentation of the input's effect.

For instance, let's say I get 30 FPS on my game. That means 30 times per second, the game is taking reading my input, handling it and displaying the effect. If you get 20 FPS, that means it happens 20 times per second. (Now that the obvious is out of the way...)

Let's say a tenth into a second, something happens. I see it and respond accordingly, as you do as well. However, with your slower frame rate, you see the situation slightly later than I do, respond later, and the game reads you input in responcse to this later than it does for me. This split second difference could cause you to miss a receiver where as I wouldn't several times over a game since I saw an opening just before you would, giving me an advantage.

Also, it means sometimes I will see something that you wouldn't. Since I'm getting 10 frames more per second than you, I get that much more information than you.

As for this game specifically, people seem to be making reference to the frame rate effecting physics. As someone who has read a lot on graphics and game engine design and programming, I can honestly say that makes absolutely no sense to me. Physics and graphics are supposed to be completely seperate parts of the overall game engine. The only thing a graphics engine is supposed to do is desplay graphics. That's it. It shouldn't have anything to do with the physics.

[wade moore]

Originally Posted by Godzilla Blitz

Ah...I see. This may make more sense. I may need to stand corrected on this, then.

Depends on if that is the issue. I don't know what the scenario is, I can't tell from the posts.

If they are in "coach only" mode (which it seems many are) then I'm with you, it makes no sense.

But if they are controlling the players, it's not that far-fetched imo based on some experience with things like FPS's when they have low frame rate and you just can't "do what you want to do"...

[Godzilla Blitz]

Found it. The following exchange is in a thread talking about play results using coach mode, which I'm guessing means that the player isn't controlling the quarterback.

Here's the comment by a gamer named Magnum:
Ok, I did what you suggested and just to let you know that my system is suppose to be under the system spec requirements, but I have been able to play the game overall. I'm only getting about a 15 Frame Per Second count which I do know is a bit slow. I find it a bit odd that the Frame Per Second would cause the problem of how the Physics work in the game. I thought the Physics of the game is handled with Math in the engine of the game?


And here is Eriks' response:
It's a combination of the two, this is why the game caps FPS at 32 and we've found that the 25-32 range is ideal though based on some testing 20-32 is the extended "everything's ok range". The minimum specs on the game were set to guarantee thatit would run in that 20-32 fps range. If you are getting 15 fps and are below the minimum listed spec, that may well be the problem.

[KWhit]

Originally Posted by gstelmack

Framerate can have an impact, but it should NEVER have a significant impact on the end result of the game. You make a conscious decision to go with a fixed-timestep sim/physics engine or a variable-rate one. With fixed timestep framerate has ZERO impact, but you have to handle interpolation between sim timesteps to keep the graphics moving. Variable-rate sims don't need interpolation, but the results can differ slightly. By "differ slightly" I mean the player may be a few inches off depending on framerate. But this should never be enough to mean that a ball wasn't caught, for example. It's just another factor to account for when writing the code.

That's a very simplified explanation. But framerate should not affect gameplay at all. It should affect visual quality, and its impact in a shooter can be noticable simply because a low framerate is annoying and difficult to control, but the results should not vary that much.

Interesting. I'm not sure I follow exactly what you mean by fixed-timestep sim/physics engine versus a variable-rate one. But it sounded like you were saying that if a programmer uses the variable-rate engine the code must be written in a way that takes framrate into account and manipulates the resulting in-game event enough so that gameplay between 15 fps and 40 fps (for example) has the same gameplay experience. Obviously one will look much choppier, but the actual gameplay wouldn't be affected. Is that what you are saying?

[Antmeister]

Originally Posted by wade moore

Right, but if a human is controlling the QB it could be a matter of bad timing, etc. because of the frame rate.. not that the physics are off, but because what you are seeing is not jiving with what you are hitting on your controller.

I will have to go look into those posts, but I remember that it was an issue for both coach mode and arcade.

[wade moore]

Since I've been a bit of a nayser...

RE: Short list of items I'm addressing. (March 4) - 3/6/2006 3:25:29 PM
Erik Rutins Administrator Posts: 7063 Joined: 3/28/2000 From: Vermont, USA Status: online	We've had a busy weekend and I thought I'd post the current list of fixes in the v1.088 beta that we're currently testing internally. Change History: v1.088 – March 6th, 2006 (First Update) Below is a list of the changes in v1.088. Fixed: 1. Fixed RTE when you create a team with missing values. 2. Fixed a hanging situation with new teams. If you created a new team, then tried to directly play a quick play game with that new team (before generating rosters for it) the game would hang. Now, if you attempt to use a brand new team for the first time with no roster, a simple roster will be generated and a basic depth chart setup. 3. Corrected several problems with the penalties. Penalties should no longer be able to cause players to line up in the end zone. 4. Reworked the random name generator so it's much faster and more random. 5. Clock properly stops on 3rd down incomplete passes. 6. Quick play games have been restricted to force the players on the field to match the chosen playbook. This should eliminate a number of errors caused by quick play settings not matching the chosen league and playbook. 7. Free agent generation for new leagues is based on position now. 8. The default draft for the 65 man roster was including far too many QBs. This could cause problems in draft mode and training camp. The 65 man default draft has been corrected to prevent this. 9. Forced penalties now properly show where the ball will be placed. 10. Fixed a bug that would see defunct teams actually take part in a draft. This could cause a valid team to not take place in the drafe (even though listed) and allow the valid team to get to training camp with no players as a result. 11. Increased the interception chance slightly 12. Changed the Play Development System (PDS) so that when practicing, only leagues/teams that match the MaxPlayers for the play you are building are displayed. For example, if you are designing a 12 man play, only leagues/teams designed for 12 men will be available. _____________________________ Erik Rutins Director of Product Development and Business Relations (in reply to Erik Rutins)
Report | Post #: 3

Looks like, if nothing else, they are working on patching. We can question their prioritizing, speed, etc.. .but it looks like they are working on it...

[KWhit]

Originally Posted by sabotai

For one, frame rate would effect the game in that it slows down the game's response to input. The slower the frame rate, the slower the game receives input from the user and that in turn creates a slower handling of the input and on screen respresentation of the input's effect.

I understand how framerate would effect user input. I get that 100%.

Originally Posted by sabotai

As for this game specifically, people seem to be making reference to the frame rate effecting physics. As someone who has read a lot on graphics and game engine design and programming, I can honestly say that makes absolutely no sense to me. Physics and graphics are supposed to be completely seperate parts of the overall game engine. The only thing a graphics engine is supposed to do is desplay graphics. That's it. It shouldn't have anything to do with the physics.

That was my thinking too. And yes, from the posts over at Matrix it does appear that FR is affecting the physics - even when no user input is made nor any needed.

[Bee]

Wow, it just gets better and better...things like punts going out of bounds and brought out to the 20 instead of spotting where it went out of bounds...Sometimes there's not a second half kickoff, you just start where the ball was spotted last. How desperate do you have to be for a graphical football game for this to be acceptable to you?

[spcd]

It seems to me, that the game has novelly re-introduced 1997-era multiplay game lag....into a single player game. A fairly remarkable achievement, almost like accidently discovering an alchemist stone for turning gold into lead.

As the problem was reported by someone trying out the PDS, I'm assuming this has nothing to do with controlling players, especially as Winter said he designed the secondary sim engine because the primary couldn't handle being sped up.

As it appears both the PDS, and Game have memory leaks, then it almost guarantees that game results will vary for a user within a particular game. I'm surprised they managed to get this out the door with any results at all, given that balancing must be almost impossible due to performance variance. Perhaps that's another clue why all the teams need superstars to play: they just couldn't balance it all.

Originally Posted by Godzilla Blitz

'd bet you're off on the buggy part of the equation. There are over three pages of reported problems with the game already, and I would think that sales of the game are quite low at this point. I bet the reason we're not seeing hordes of bug reports is simply due to the fact that not many people have the game, and many of them appear to be stuck getting the game to work properly in the first place.

Possibly, though I have been eliminating anything which looks to be consequential to the design, and the success they appear to have had in diagnosing and fixing display issues. Even a small audience would have problems if it was an unmitigated buggy mess.

I'm beginning to see why even small build changes resulted in so much testing the last few weeks, with the number of variables, and a variable result-engine, they've probably been wasting man-weeks trying to figure out what's wrong.

----

JonInMiddleGA
Just to add, this is the type of game which would be too expensive in wasted time if they gave it away for free. It's a damn shame, as some of the concepts could have resulted in the successor to Front Page.

[Antmeister]

Oh geez....

Even David talks about frame rate affecting the physics of the game.

http://www.matrixgames.com/forums/fb.asp?m=868601


"The only reason I've not released a video is that no video software I've tried (from FRAPS all the way up to the $1000 video editing tools) captures the game at a quality video rate. The game runs at about 60FPS (completely system dependent obviously) but as soon as I run FRAPS or some other video capture software the frame rate drops to about 10 or 12. This really impacts the quality of the animation (it' becomes very choppy). If the frame rate drops too low (under 10) even the physics engine is effected. So rather than release a video of a game running at a poor video rate, I've not released any at all.

As was mentioned, many people saw it at a pro football game last year (long before some of the new features were added) and nobody had any complaints with the animations (at least no one mentioned them to me anyway)."

[Antmeister]

dola....

And that was just talking about showing a video clip of the game.

[sabotai]

Another gem from Daivd...

"Actually I'm using exactly the same technology other developers are using. DirectX is DirectX is DirectX..."

See, he's using DirectX. That means it's Microsoft's fault and not his engine design.

[st.cronin]

This game would have to come with a free computer for me to consider it.

[albionmoonlight]

Originally Posted by spcd

It seems to me, that the game has novelly re-introduced 1997-era multiplay game lag....into a single player game. A fairly remarkable achievement, almost like accidently discovering an alchemist stone for turning gold into lead.

[Antmeister]

Originally Posted by st.cronin

This game would have to come with a free computer for me to consider it.

It depends on the computer for me.

[Antmeister]

This thread used to be so fun, but it has evolved once again into a serious discussion about game design, business practices and questionable code. What is the next thing that this thread will morph into?

[Godzilla Blitz]

Originally Posted by spcd

As it appears both the PDS, and Game have memory leaks, then it almost guarantees that game results will vary for a user within a particular game. I'm surprised they managed to get this out the door with any results at all, given that balancing must be almost impossible due to performance variance. Perhaps that's another clue why all the teams need superstars to play: they just couldn't balance it all.

The 1280-players-per-position player database at league creation and the 40-60 rounds per annual rookie draft default settings really jumped out at me in flashing red letters. I mean, those aren't things you do by accident. It would appear now that they are designed to completely mask a dysfunctional player rating system.

The proof will be when reports come in as gamers try to play games with non-superstar teams, or as they try to modify the player-generation parameters to create leagues with more balanced player ratings (in effect, as gamers try to "customize the game"). As it stands, it doesn't seem like this is easy accomplished in the game's current state. Randomly created players have the same ratings (in the 30's) and you must manually edit each one to change the ratings. There are league creation figures that can globally modify the number of rounds and players ratings, but the only person who seems to have tried that couldn't get it to work correctly.

[sabotai]

Originally Posted by Antmeister71

This thread used to be so fun, but it has evolved once again into a serious discussion about game design, business practices and questionable code. What is the next thing that this thread will morph into?

A werewolf game?

[albionmoonlight]

Originally Posted by Antmeister71

This thread used to be so fun, but it has evolved once again into a serious discussion about game design, business practices and questionable code. What is the next thing that this thread will morph into?

But, see. That's what makes this thread fun. The fact that the vast majority of us are actually rooting for the guy and want him to make a good game. This would have just been some sophmoric episode on the internet if we were simply engaged in schadenfreude or even actively trying to hurt the game's chances of succeeding. Anyone can be a nay-sayer or a critic.

We, however, actually LOVE games like this, and we can't help ourselves from seeing what neat things exist in at least the idea of the game. And we can't help ourselves from going into constructive criticism mode. That's just who we are. We want this game to work and we want to do what we can to help make it work. That's what makes this thread great.

Anyone can make jokes. True comedy comes from the seriousness underlying the jokes.

Unfortunately, I get the sense that we came off to Davied as simple nay-sayers and hucksters. And he didn't think to ask what we were really laughing at until it was too late.

[spcd]

Originally Posted by Godzilla Blitz

The 1280-players-per-position player database at league creation and the 40-60 rounds per annual rookie draft default settings really jumped out at me in flashing red letters. I mean, those aren't things you do by accident. It would appear now that they are designed to completely mask a dysfunctional player rating system.

I assumed initially, that this was to make up for a poor (or missing) draft/depth-chart/training/substitution/management AI. If there was any difficulty in those areas, which tend to be difficult challenges for experienced sim engines, then having parity on any level: star-average-awful, would at least ensure that the AI stuck the right players out there. But, it could definately be affected by the results testers were seeing with the engine fluctuation. Combine that with multiple-builds, regressive bugs, and new features, and you can imagine how futile and time wasting the process has been

Tester 1 "my quarterback never hits the WR"
Tester 2 "my quarterback never throws an incompletion"
Winter "let's change the ratings"
Tester 1/Tester 2 "it works now"

when the symptom could have simply been variable frame rate and the "resolution" being confirmed solely by the chance confluence of both testers machines during a particular series of tests. They do seem aware of the problem, the 22-30 FPS being reported "ok," but I really don't see how anyone could have that level of confidence, especially in a genre where the smallest offsets and balancing issues are usually what makes or breaks a game.

Randomly created players have the same ratings (in the 30's) and you must manually edit each one to change the ratings.

If I had to guess, because parity seems to work, regardless of where on the curve that parity is. You're right, it will be interesting to see what happens when the skill levels vary significantly between players. Might be another clue as to why there seem to be so many things which break the AI.

[CamEdwards]

I like this quote from Daivd:

We had two coaches and two semi pro quarter backs on the beta team. The rest were, at least, very football savey. The feed back from them was the PDS was pretty much doing everything they expected.

Yes, there have to be some restrictions on some things because there is simply no way I can create encough code to handle every possible thing everyone would like.

I have big plans for the PDS. I won't go into them all now but I have a lot of things I want to do with it to improve it.

Ooooh, secret plans! And coaches on the beta team! If you don't like the game, it's the coaches fault.

[JPhillips]

Pretty much doing everything they expected

is very different from

Pretty much doing everything they wanted

[Godzilla Blitz]

I've probably spent 10 hours or more following this release over the past week, and most of it has been with the same kind of curiosity that I have as I look at a bad car accident. At one point, I suppose I had hope that everyone in the accident would turn out well, but that hope faded a few hours after release. Even when I knew that things weren't going to turn out well in my eyes, I kept watching though. Car accidents are so amazing.

At some point today, though, my fascination has morphed into the feeling that well, perhaps there is something wrong for me stopping and watching a car accident for so long and with such fascination. I feel like I'm just kicking the victims at this point, when in reality I wish them good luck in getting things on track. I doubt I have the self-discipline not to read this thread, so I'm sure I'll read everything anyone writes, but work has piled up and there is life to be lived.

It's strange, though. In some bizarre manner, this thread has inspired me. I started to learn to program about a year and half ago, and started to try my hand at creating a simple text-sim. After a while I sort of stopped working on it, and the plan fizzled into nothing productive. I have no idea how this has happened, but for some strange reason, after following this release I have a stronge urge to get back to work on that. Go figure.

[FrogMan]

Originally Posted by Bee

Just saw a thread where no one has seen a fumble yet. Do they have fumbles in Canada?

never heard of them personally. But we did have some funballs, or at least that's how a guy on my senior football team called them

FM

[gstelmack]

Originally Posted by KWhit

Interesting. I'm not sure I follow exactly what you mean by fixed-timestep sim/physics engine versus a variable-rate one. But it sounded like you were saying that if a programmer uses the variable-rate engine the code must be written in a way that takes framrate into account and manipulates the resulting in-game event enough so that gameplay between 15 fps and 40 fps (for example) has the same gameplay experience. Obviously one will look much choppier, but the actual gameplay wouldn't be affected. Is that what you are saying?

Actually, you can get them both to look about the same.

In a fixed-timestep sim engine, every update on the sim loop assumes the exact same amount of time has passed (say, 1/30th of a second). So, if you are running at 60FPS, you only update the sim every other frame. Then the graphics code takes positions and velocities from the sim and figures out where everyone is on the screen this particular frame. It sounds like things would be choppy, but the reality is the AIs aren't going to completely change what they are doing all that often, so it works fine. If your update rate is slow enough, you can get things going through walls, etc, but at 1/30th of a second update time you're not likely to notice.

In a variable timestep engine, you figure out how much time has passed since the last update and use that. So, at 60FPS, your frame time is 1/60th of a second. But on another machine someone might be running at 72FPS, so the sim has frame times of 1/72nd of a second. The sim updates itself accordingly.

Where these differ is in the results of the physics. Say you are throwing a ball in a 3D world. Curves are too expensive to compute (or more importantly do collision detection on), so you use line segments to simulate. You figure out how far it would move this frame, add in gravity, and see where it ends up. If your frame times differ, you'll end up with slightly different paths for the grenade. You're doing a piecewise approximation of the path, where your pieces will have varying lengths, so the path is slightly off.

In an FPS, this could mean the grenade hits on one box where it would just barely clear the wall on another, but not enough for anyone to truly notice. But where it HAS been noticed in the past is in something like say jump distance. You get your framerate down low enough in some early shooters and you could jump farther, clear taller obstacles, etc. So you need to do something to deal with the issue.

One way is to break up long pieces into multiple smaller ones. So, if your frame rate is only 10 FPS, you might update your sim twice for an effective 20FPS. Or just break up the small tasks where needed: if your movement piece is longer than 1 meter, simulate it in 2 0.5 meter chunks. Another is to put a min cap: if your frame rate dips too low, you can slow time down a bit. If someone is running at 8 FPS, they aren't going to notice that time is moving slower than normal thanks to the low frame rate.

You usually have to do something in either case, as you need to deal with high velocities. This is called the "bullet through paper" problem: the bullet moves so far in one frame that you never see a collision with the thin obstacle in the middle of its path. So you need to do some sort of intermediate collision steps or breakdown of the path. You end up with a hybrid of the two: most variable-rate engines will have some sort of fixed-step algorithms in them to deal with high velocities. And even a fixed-step engine needs to deal with this for high-velocity objects.

As with anything in game design, there are tradeoffs and issues to deal with either way. Variable-rate engines mean the rendering engine doesn't need to have interpolation as the sim is up-to-date, while fixed-rate engines tend to have more stable math. But you have to pay attention to both to make sure the physics work.

[JonInMiddleGA]

Originally Posted by Godzilla Blitz

but for some strange reason

Masochism?

[KWhit]

gstelmack:

Thanks for taking the time to reply. That makes a lot of sense and is pretty fascinating to me. I've never really understood how game engines work and this is shedding some light on that.

So to follow up, it seems that this is a key statement you made that may explain what it looks like is happening in MF:

Originally Posted by gstelmack

Where these differ is in the results of the physics. Say you are throwing a ball in a 3D world. Curves are too expensive to compute (or more importantly do collision detection on), so you use line segments to simulate. You figure out how far it would move this frame, add in gravity, and see where it ends up. If your frame times differ, you'll end up with slightly different paths for the grenade. You're doing a piecewise approximation of the path, where your pieces will have varying lengths, so the path is slightly off.

Let's see if I've got this right. In a variable time-step engine, due to the length of time between frames, certain logic (like gravity to use your example from above) will execute more often on a machine with a higher frame rate. So it's possible that the same pass play downloaded on two different computers could result in very different outcomes when run in the game. Even though the play might be exactly the same, gravity might make the pass fall to the ground at a shorter distance in-game on one versus the other because of their frame rates and how often certain logic is run. Right?

Because of the nature of the Play Development System in MF and the desire to share playbooks online, this seems like it could cause pretty significant problems. I saw that one thing Daivd has done to try to alleviate this is to put a FR cap on the game at 32 fps. I would imagine that there are other things that could be done to the code to tighten things up further. I would imagine that results could be quite different between gamers that can run the game at 32fps and those that can run it at 20fps. Do developers typically try to account for this type of discrepancy as well? Is that something that should be expected of a developer who uses a variable time-step engine?

I'm not trying to be nit-picky here and bash MF. I ask because I have never heard of a situation where frame rate affects the actual gameplay, so there must be something that developers do to account for varying framerates, right?

[gstelmack]

Originally Posted by KWhit

Let's see if I've got this right. In a variable time-step engine, due to the length of time between frames, certain logic (like gravity to use your example from above) will execute more often on a machine with a higher frame rate. So it's possible that the same pass play downloaded on two different computers could result in very different outcomes when run in the game. Even though the play might be exactly the same, gravity might make the pass fall to the ground at a shorter distance in-game on one versus the other because of their frame rates and how often certain logic is run. Right?

It can, certainly, but I'd consider that a bug in my engine. The key is that if you discover that a player can jump much farther at 10 FPS vs 60 FPS, you go back and change the jump movement code to simulate multiple shorter segments to bring it all back in line.

In other words, there are ways to mitigate the effects. The reality is every engine has a bit of both, with variable-rate engines doing some fixed-rate bits to reduce these issues, and a fixed-rate engine moving some variable rate code (interpolation) into the rendering bits.

[KWhit]

Originally Posted by gstelmack

It can, certainly, but I'd consider that a bug in my engine. The key is that if you discover that a player can jump much farther at 10 FPS vs 60 FPS, you go back and change the jump movement code to simulate multiple shorter segments to bring it all back in line.

In other words, there are ways to mitigate the effects. The reality is every engine has a bit of both, with variable-rate engines doing some fixed-rate bits to reduce these issues, and a fixed-rate engine moving some variable rate code (interpolation) into the rendering bits.

Okay. I think most of us raised our eyebrows when Matrix/Daivd mentioned that the physics were affected by the frame rate. It sounds like that is explainable from a programming point of view, but it is something that should have been accounted for in the game code (in other words: a bug).

[Ben E Lou]

FPS talk finally kills this thread?

[Antmeister]

Originally Posted by SkyDog

FPS talk finally kills this thread?

No the thread is waiting for its next mutation.