One place where polymorphism is used to model "game objects" in simple games. Such games might have an abstract "Game Object" or "Entity" class, from which all objects in the game derive from. This might have a handful of virtual functions, such as one to advance the object's state by one frame, and another to draw the object. Much of the higher level code can be written in terms of these game objects, the exact type of which is irrelevant. From the game's point of view, a Kitten and a Space Marine are essentially the same, they both need to be moved every so often, and they both need to be displayed.
In complex games, such as AAA games, a simple model like the above is not used. One reason is the number of classes that would be required becomes too much. Another, is that handling object specific behaviour may be delegated to a script files that are loaded at runtime rather than compiled into the executable.
Another place I see people using polymorphism is for managing the main menu, settings, running game and pause screens, etc. A class might be created called "GameMode" or "GameState". A concrete subclass could be created for a the MainMenu, PlayingGame, PauseScreen, and so forth. Much like the game objects, these might some virtual functions to update and render. They might also need functions to react to input events. Finally, a mechanism for transitioning to the next state is needed. One way to do this is to have the update() function return a smart pointer to the next mode or state, if a transition is to be made. If no transition is needed, then no pointer is returned.
This can sometimes be modelled as a simple GameMode/GameState enum, which dispatches to various state-specific functions, avoiding the need to create a class hierarchy.
In general, the more important thing is to know when to avoid polymorphism. Programmers who are not experienced in object oriented programming tend to over-use inheritance. While mostly harmless, in some cases misusing inheritance can degrade the code quality. In most games, there wouldn't be dedicated Cat and Dog classes. These game objects typically are quite similar for most intents and purposes, the differences are not in the actual game object behaviour but in their data.
Even a moderate sized game might instead have a general Animal class rather than specific sub-classes. The Animal class could take a variety of arguments to the constructor including what texture and meshes it should use, which sounds it will play and what speed and ferocity it has. This data can then be easily moved into a file, which the game loads. This would allow the game designer to quickly tweak how fast a cat runs, without needing to recompile the entire game executable. This flexibility would allow you to bring your game to play test at a friend's house, where when you realise during the test that cats are too slow and are not correctly balanced, you can change the value there and then and test that the new one is better.
A counter example might be if the game models the animals in such detail that each class would have unique behaviour, for example, a cat landing on their feet after a fall, but a dog would not. In this case, it may be preferable to have two classes to handle this, than to try treat this as data (e.g. a "will_land_on_feet_following_fall" boolean).
As you can see, there is no absolute right answer. Coming up with and evolving designs for these scenarios and more is a skill that you hone by making bigger and bigger games. What works for Pong will often not work for GTA XXVII, and overengineering the code for a simple game wastes lots of time that could be spent making the actual gameplay more fun, making better assets or recruiting artists, all of which would be more valuable to the player.