Don’t call it empty, make it empty

Game project.

True story.

Benefits?

Yeah, there is one.

That condition just looks nice.

OK, I don't get what's wrong here

Imagine situation when there are some cards which don't have backgroundImageName because they're deserialized from some server JSON data.  When this field is empty we need to fill it:

In such cases we may miss that our card is of type EmptyCard. As we continue we try to fill it with missing data based on... missing data (there is no faction inside). Two failures at once!

Also that comparison and many checks of values for certain fields - is it null or is it empty String? For me it's a third failure.

Alternative

Alternative is to not use Card object with empty fields. It's better to just give null instead of whole empty object. Doing so you will be sure that no one fills EmptyCard object (got as Card reference) by mistake (as in last code snippet).

And if you really, really want to check whether object is not being filled, it's better to use some method for it. It's always based on context but here still I don't recommend it.

Conclusion

You should consider yourself what you want to tell other programmers. But to me using such EmptyCard classes is just hiding some important things for new developers who may not notice such "important" buggy class which does not have any role in OOP and its use does not seem to be coherent in any way with logic layer.

And hey! Does it look that bad?