Building on what Nick said, the idea of casting basically comes from the world of programming. Without getting too much into programmer town, the basic gist is that blueprints and actors can be parented off of one another, which leads to separate, different blueprints that have some things in common.
A simple way to learn the concept might be with an example. Pretend you make a blueprint that represents a generic animal. Inside the blueprint, you implement some basic functionality that all animals have in common. For this example, pretend all animals have to eat and you make a function called “Eat.” Now, later on, you want to make a blueprint for a dog. A dog is an animal, so you make the dog blueprint be a child of the animal blueprint. This makes it so that the dog has gained all of the things you implemented in the animal blueprint, but also allows you to add some new things or to change things around (pretend the dog eats in a different way from the generic animal and we want to change what “Eat” does…we can do that). Likewise, now that we have a dog, pretend we want to make a blueprint for a particular breed of dog, like a Golden Retriever. Well, a Golden Retriever is a dog, so it makes sense to make the new Golden Retriever blueprint a child of the Dog blueprint, which itself was already a child of the Animal blueprint. We could continue to do this with many, many different animals, dogs, etc. At this point, we might have a simple hierarchy like this:
Ok, so that’s great, but how does that explain why it’s useful, or what casting is? Well first, the powerful part is that all of those things in the hierarchy share whatever was added in their parents. So if we added that “Eat” function to Animal, every child animal we add also can eat. They might eat differently (so their blueprint would change the behavior a little bit), but we are guaranteed that every animal can eat, which lets us do some powerful things. Continuing our silly example, in this case it means if we had a blueprint that was representing a zoo (it holds an array of Animals), it could call the Eat function on each Animal in its array of Animals without ever knowing a single detail about any one individual animal. It doesn’t matter that the array actually holds one tiger, an elephant, a bear, etc. We can just go through each element in the array and tell it to Eat, because we know all animals should eat and that each animal knows what that means to them.
So where does casting come in? Well, if we’re storing all of our variables just as simple Animals to enable this powerful behavior, it means at first glance we’ve lost access to specific features of particular animals. Let’s say when we made our Dog blueprint, we added another function to it called PlayFetch, because we wanted all of our dogs to know how to play fetch. Animals in general don’t know how to play fetch, but dogs do. However, in our zoo example, we only know we have animals, not if any of them are dogs…so how do we make them PlayFetch?! This is where the cast comes in. On each animal, we can attempt to cast it to a dog. In essence, we are asking the animal, “Are you a dog?!” If the answer is yes, then you are given back the same variable, but very specifically as a dog this time, which allows you to call the PlayFetch function if you want. If the answer is no (you asked a cat if he was a dog!), then the cast “fails” and you’re returned nothing, because a cat is decidedly not a dog!