next »

[J-Snake]

I am considering to jump to unity-engine. However it seems not practicable to implement an interpolated fixed timestep there. But that is my way to go because I want:

1. same and consistent rules/game-logic on every system
2. fluid visuals (no stuttering or jitter)


So I totally disagree with that blind trend in the unity-community to only recommend fixed-update for physics, it should be applied to game-mechanics aswell. Ideally it should be applied to everything if performance isn't an issue. However there is one heavy reason to avoid fixed step left: jumpy visuals.

For example I want to know how does a regular unity-user implement jump-mechanics? You cannot just apply linear scaling based on elapsed time. It is only valid for linear-motion. In general you would need something like the RK4 integrator to make it properly. And still the results are not always the same because of numerical errors.

So what is your take on all this?

[gimymblert]

Most unity coder are beginner with strong artistic background and do not do hard core competitive game. Unity allow them to easily realize their dream without the hassle of usual code workflow as you can work with art asap and have something showable before dealing with behavior.

Regarding these condition the trend is healthy to them. Experience dev would be able to do the correct decision with informed rational.

[gimymblert]

But it became an input issue too and you should keep those points in mind I mentioned regarding it.
I still would like to know how much frames your sample can output, if you don't mind.

I don't understand. However i'm not yet conducting precise metric because i don't need them

[Danmark]

However it seems not practicable to implement an interpolated fixed timestep [in Unity].

It's already implemented for you- see Rigidbody.interpolation (curiously called (edit) Interpolate in the Inspector). Never found the need for it though. Only worry about jumpy visuals once you've observed them.

So I totally disagree with that blind trend in the unity-community to only recommend fixed-update for physics, it should be applied to game-mechanics aswell.

Wasn't aware that Unity users feel this way, but yes, game logic should go in FixedUpdate().

For example I want to know how does a regular unity-user implement jump-mechanics?

If the character's feet are on the ground and he's been instructed to jump, apply an impulse upwards. Of course this is for FPS-style jumping. Can you be more specific on what you're trying to achieve?

[J-Snake]

I know there is an interpolator. But it only applies to its own physics. I want a general system for myself. I don't even want to use any of Unity's physics.

Game-Jump-Mechanics are usually this:
speed+= gravity;
pos+= speed;
.
.

But using Update (variable step, not fixed) many will likely do it like this:

speed+= gravity* deltaTime; //this line alone will make jump-physics inconsistent
.
.



I have edited my last post in your thread, please reply on the fixedUpdate-rate here, I would like to know this is the issue.

[Danmark]

I want a general system for myself.

Why?

I don't even want to use any of Unity's physics.

Why not?

Again, be specific. Few people will be willing to help you if they must interrogate you on what exactly you want.

Game-Jump-Mechanics are usually this:
speed+= gravity;
pos+= speed;

Not quite. More like

acceleration += gravity
...
velocity += acceleration
position += velocity
acceleration = 0,0

[J-Snake]

Lol, where is the difference? You just added two lines of unnecessary overhead. What you are doing is exactly the same.

Interpolation does only work for unity-physics, is that right? I mean if I make my own controller for player-movement which is not based on forces, just my own code, will it interpolate? But may be I will just do everything in fixedUpdate except for the camera-movement, perhaps the results will be sufficient if I make the camera-movement in update. I want a silky-smooth picture, but game-mechanics in fixedUpdate, thats all.

[Danmark]

Lol, where is the difference? You just added two lines of unnecessary overhead. What you are doing is exactly the same.

That depends on how it's used, but in any case, it's far more versatile with a separate acceleration vector. I often find that object velocities are very important throughout my game logic, so affecting velocity directly whenever forces are applied, rather than in a single step across all physical objects, introduces an unwanted dependence on the order objects are updated in. Also, for audio or visual effects, you might want to know how much an object accelerated during a frame, which is unknowable in your scheme.

Also, your terminology is incorrect. Speed is a scalar, velocity is a vector. I'm not just being pedantic. If you ever intend for others to read your code, you need to make sure you use clear words.

Interpolation does only work for unity-physics, is that right?

You could roll your own easily enough. I'm just don't see why you'd bother. The only reason not to use Unity's built-in physics is because it's not practical for what you want to do, which I highly doubt. What exactly is the physical behavior you're looking for?

[J-Snake]

It is not relevant how you structure things in a more complicated scenario. I just show you the basic jump-mechanics. And I don't think it is confusing to get 2 lines of code. If I would call them differently it would still be of no help since you are looking at the wrong things.

This line should be relevant to look at to see the inconsistency you will get with update:
speed+= gravity* deltaTime; //this line alone will make jump-physics inconsistent

If I want to roll my own interpolation system then I need the left time after the last fixedUpdate (it is not deltaTime between two update-frames) and a draw-call for every screen-refresh. Then it is only used for visual interpolation which means that I need access to manipulate only the drawn-picture of objects, but not the objects themselves, of course. I don't want to manipulate the position of objects but only the visual feed-back.
It applies to everything that translates in position. That needs to be smoothed out, not only the objects whith a physics-component attached to them.

Do you see my problem?

[J-Snake]

To understand my problem you will need to understand the point of the game-loop in "Free the physics"-chapter. And then you need to see the use of "remaining time" in the following "final-touches"-chapter.

http://gafferongames.com/game-physics/fix-your-timestep/

I think it is not practicable to make a work around in unity to achieve the same results. But I will think about the camera controls. I can put them in update since they don't change the game-mechanics. If they are in update, they will at least translate smoothly. And may be that will suffice for an overall smooth experience.

[CowBoyDan]

Hi, found the thread J.

Something to keep in mind is that all game physics are approximations, they will get more accurate as the time step size approaches zero.  I asked in the other thread how this will affect the user experience (or something like that), if you crank of the time step (or down depending on how you look at it) to 1/120 of a second (assuming you think 1/60 is noticeable), how will the end result be different than what you want to do?

Interpolation would be much more important if we were talking about 1/10 second steps, but in many games the physics steps run the same speed or faster than the screen refresh (games may report 800 frames per second, but if your monitor is 60 hz, you are only seeing 60 of them)

[J-Snake]

There is a fundamental misconception on your side. The problem here is not making the physics as accurate as possible, it is about making them consistent. For example I have a grid-based action-puzzle-game. It requires floating-point operations for movement. There are some very tight situations which require perfect controls (you have a clean time-window and input in advance to move perfectly around corners and such). When I use a variable step I cannot guarantee to succeed all the time despite I am doing the exact same thing. In fixedTimestep however I can reproduce the same result over and over again because it is the EXACTLY SAME game, no matter where and when you play it.

Perhaps you understand more about the problem now.

Interpolation is always needed for a silky-smooth visual output in fixedUpdate, regardless you update in 10hz or 100hz. To see it you need a detailed picture about how the fixedUpdate-gameloop actually works (the article is a good reference for that). The main problem is solely that its update-rates don't match up with the screen-refresh-rate. If your screen is 60hz and fixedUpdate is 100hz it is still the same problem, sometimes the fixedUpdate will be called 2 times in a row, then only 1 time, and whenever this occurs you will see the corresponding visual output. If you move something by 1 frame and the next frame by 2 frames, that is where you notice a jump in translation. You will need to interpolate the visual outcome to smooth that out.

How to keep consistent mechanics and still providing smooth visuals is all the motivation why the article I posted was written.

[gimymblert]

So the problem in a nutshell: you want to sync "frame" (update) with fixedupdate

or

you want to smooth the frame according the fixed update it fall between



you can call rendering independently in unity i believe

[CowBoyDan]

I understand the concept, I've read that article before.  I think I misunderstood what you were interpolating, you are talking about interpolating the RESULT of a fixed step is that right?  

I've personally never been bothered (not sure I've conciously noticed) the problem, when I've actually watched frame rates they have been quite variable, fixed update is meant to help solve the problem of highly variable framerates.  If I were making a game that depended heavily on 1-2 frame twitch input I would probably approach the problem differently (require 60 frames per 1 second of game time for instance, and if the frame dropped to say 30 fps, 1 second of game time would approach 2 seconds of real time and if it approached 90 fps it would delay until the next frame time), alah the time slows down when it cannot keep up.

I can't say I've played many games that sound like yours (the frame consistency requirement), I'll have to try it sometime, the I might understand better.

[Danmark]

This line should be relevant to look at to see the inconsistency you will get with update:
speed+= gravity* deltaTime; //this line alone will make jump-physics inconsistent

I ignored it because it's a red herring; everyone (including you) already knew it's inadequate. My comments on the other scheme were an aside, so you can take them or leave them, but please don't admonish me for being helpful.

Do you see my problem?

I do now, because you've finally asked a specific question. I'll start by pointing out that you probably want extrapolation, not interpolation, since it would feel more responsive to players, and any artifacts arising from (edit) incorrect prediction should be easy to iron out. It's also possible to do both interpolation and extrapolation at the same time, but I don't know the details.

The time side is simple enough with Time.time and Time.fixedTime. What makes it difficult is, as you allude to, the way Unity deals with transforms. You'd need a dummy transform component to preserve objects' transforms so the real ones can be temporarily overwritten with their extrapolated values for rendering. I suppose you'd actually need two components either end of the FixedUpdate phase, the first setting the real transforms to the dummy transforms, and the second setting the dummy transforms to the real transforms. Note that you can set the script order in Edit->Project Settings->Script Execution Order. Of course, the only reason you'd do any of this is if you had your own physics, and the script for that should be somewhere between the two bookends.

Next, during the dummy transform's Update(), you want to extrapolate by Time.time-Time.fixedTime according to the objects' velocities and (if relevant) angular velocities. If you wanted to do interpolation instead, I think you'd need a second dummy transform (which could still be part of the same component, so each dummy transform component holds two states.

It might be easier in Unity Pro with the Graphics class (wouldn't know).

It applies to everything that translates in position. That needs to be smoothed out, not only the objects whith a physics-component attached to them.

Everything that translates continuously ought to have a (kinematic, at least) Rigidbody attached. This also applies if you do your own physics.

To understand my problem you will need to understand the point of the game-loop in "Free the physics"-chapter.
...
I think it is not practicable to make a work around in unity to achieve the same results.

I've read Fix Your Timestep more than once. You'll find most people here have read it, since it's a canonical article on game implementation. Anyway, now that I've thought about how it could be implemented, I agree that it's not practical. I'm still skeptical that you need such a thing though. Why exactly can't you use Unity's physics? Even hacking around them a bit would be easier than doing your own.

[J-Snake]

I don't think most of the people have read this article or at least the point of it since you would be aware about my problem since the first post. I stated exactly what my problem is and what I want.

No, I do want to use interpolation, not extrapolation. For my current game (TrapThem) I could get away with extrapolation but in general it is not a good idea for interactive physics. The game has the same response, regardless you use interpolation or extrapolation. By using interpolation it is only that the visual-output is just one frame behind the update. But my games are running fast at 60 or even 120hz anyway so it doesn't matter anyway. On the other hand it has even natural advantages. Interpolation has a smoothed out effect that prevents moving things to look like they stop immediately. Even when you stop something immediately for the next game-frame, you will see a frame in between (whenever there is a screen-refresh inbetween) until it stops in the next game-frame. It means Game-mechanis are still exact and direct like you want them to be, but even then it looks still a bit smoothed out, and that is cool.

Extrapolation gives you visual artefacts  when you physcally interact with something. For example if you land on the ground you can often see your character a bit under it until it is placed correctly on the surface in the next frame. With interplation it cannot happen since you only make something between already existing game-states, there is no need for prediction.

Like you see the work around is not practicable but I will see what I can do.

Other than that I am also interested to see what you guys think about unity. Is there someone here who uses it professionally? I heard EA bought it aswell, I guess for some smartphone stuff. Btw. how is cross-platform development for smarthphones going? Is it all well supported?

[J-Snake]

So if it is the way it sounds:

I can attach a physics-component or whatever it is called to every object that moves and interacts with the world, including my player, then indeed, my problem is solved. I just need to turn on interpolation.
I guess I need to check out unity and see for myself.

[Bryant]

So if it is the way it sounds:

I can attach a physics-component or whatever it is called to every object that moves and interacts with the world, including my player, then indeed, my problem is solved. I just need to turn on interpolation.
I guess I need to check out unity and see for myself.

Did you get a chance to try this out J-Snake? Any luck?

What other frameworks or engines get this problem right? If I'm designing a competitive fighting or rhythm game, for example, I need to be able to trust that my implementation is perfectly timed. But it seems like this stuttering problem is all over the place

[dustin]

for a competitive fighting or rhythm game I'd say you pretty much have to go with C or C++.  You could probably get away with java + slick also. 

Not to say you can't make an in browser fighter/rhythm game, just that they will lean more towards the casual.

[Danmark]

I don't think most of the people have read this article or at least the point of it since you would be aware about my problem since the first post. I stated exactly what my problem is and what I want.

Sorry, but your first post was confused, and asked an apparently open-ended question. If everyone has trouble understanding you, it's probably your fault.

The game has the same response, regardless you use interpolation or extrapolation.

True, hence I said feel more responsive. In theory, because you're outputting to a discrete display, it could be more responsive, i.e. the image changes the next frame given the player's input rather than 2 or more frames in the future, but it's not likely in any case.

Other than that I am also interested to see what you guys think about unity. Is there someone here who uses it professionally?

I used it professionally for a few months. It's great when none of its restrictions happen to be in your way, and rather infuriating when they are. It's also fairly buggy, which is to be expected from such a complex piece of software. I'm convinced there's no better tool for prototyping game ideas.

I can attach a physics-component or whatever it is called to every object that moves and interacts with the world, including my player, then indeed, my problem is solved. I just need to turn on interpolation.

That's right. You'll get shit done faster that way than you would making your own physics, which would be both tremendously time-consuming and futile, as the finished product would still be inferior to PhysX.