Hello.
I'm a beginner in game programming. (Now I'm not using an engine)

I have a couple of questions..

1. In game programming, what use base thing for updating an animation? (tick? elapsed time?)
   i.e. if(…) { UpdateAnimation(); } // using time or tick or other thing?
   
2. What is the name of a function that update frame usual? In my case, I use a name like UpdateGameFrame or OnFrameMove. but I want to know a common name.
   

Thank you.

I don't think there are really any hard set conventions for either of your questions, but I'll try to answer with generalizations that usually work well and are commonly used in game engines:

1. For running animations you usually update the bone transforms (or whatever kind of animation transforms you're using) per frame, to get smooth motion, so you want to “tick” your engine per iteration of your game loop. Whether or not your animation code is running on a separate thread, you usually want to interpolate the positions between frames using some sort of delta time (time difference between last and current frame) in order to get animations that play at consistent speeds across different CPUs (due to different clock speeds for different CPUs, depending). So in a way, you want a mixture of the two things you mentioned.
2. Like I said, there's really no conventions for this. You could call it whatever you want. That's the beauty of programming. In general such methods are named after some flavor of Update or Tick or Loop, or something descriptive like that, but you know, your code your choice.

EDIT: Some pseudo code for your first question might look like

while(gameIsRunning)
    float currentFrameTime = getCurrentFrameTime();
    float deltaTime = currentFrameTime - lastFrameTime;
    lastFrameTime = currentFrameTime;
    ...
    UpdateAnimation(deltaTime)
    ... 

@skatehumor Thank you for the answer!

skatehumor said:

while(gameIsRunning)
    float currentFrameTime = getCurrentFrameTime();
    float deltaTime = currentFrameTime - lastFrameTime;
    lastFrameTime = currentFrameTime;
    ...
    UpdateAnimation(deltaTime)
    ... 

That might work, but can be very sensitive to framerate changes (although it shouldn't, it might!)

One article that keeps appearing here (for a good reason) is Fix your timestep. It discusses and explains how to nicely separate drawn frames from timing.

@supervga You're not wrong. Just trying to provide a minimal starting example so the OP has a basic idea.

On another note, this is usually why you scale things such as animation or user controlled (non-physical) motion based on the delta time difference, to avoid such inconsistencies (sometimes clamping the delta to certain maximums and minimums to avoid extremes). I've come across the article you linked a few times now and it's definitely recommended reading but note that the article is mostly talking about time steps in physics simulations. You usually want to fix your timestep or run multiple physics iterations based on the delta time in order to avoid strange physical inconsistencies. I've tried implementing my own physics engine in the past and often ran into janky collision resolution behavior for this very reason.

But when it comes to rendering you sometimes don't want to limit the framerate of your game and want the rendering loop running as fast as your rasterizer can draw images and your screen can display them. Drawn frames and physics iterations don't always correspond. A game without physics or collision handling (rare but it can happen) might not even require such a loop. On the other hand, if you are developing on non-console hardware and want to provide a fixed framerate for your games you probably want to take suggestions from the fixed timestep camp.

EDIT: Unity just posted an interesting article about how they fixed their delta time in the 2020.2 update