Interfaces without methods vs fields

I have two classes, LivingCreature ,and Animal which inherits from it.

I want to implement a class for each existing Animal, but since different animals share lots of features, I want to be able to classify Animals into several categories: Flying, Walking, Swimming, Carnivore, Vegeterian and so on...

Every animal can reside in several, even from the same area, for example Flying, Walking and Carnivore.

Also, each category may hold several unique attributes, for example a flying animal should consist speed and eating type (e.g. whether it sits on a tree picking worms, or "raiding" the earth and picking animals with its legs)

The First thing that I definitely want to avoid is to hold a different set of fields for each concrete animal implementation.

Now, since some categories are simply binary (Carnivore or Vegan) and some are definitely not, I wonder what would be the right way to implement it.

I tend to go towards interfaces for each category, even if they won't be holding any methods , but I'm encountering a conflict:

• It looks odd to hold an interface for such simple use like isMeatEating which holds a single boolean field.
• On the other hand, having several categories as Animal's fields and several others implemented as Interfaces, sound very wrong and confusing.

What would be the correct/best option here, design-wise? (Perhaps there's a design pattern which matches this use-case)