Composition and Interface Inheritance are the usual alternatives to classical multiple inheritance.

Everything that you described above that starts with the word “can” is a capability that can be represented with an interface, as in ICanBuild, or ICanFarm. You can inherit as many of those interfaces as you think you need.

public class Worker: ICanBuild, ICanFarm
{
    #region ICanBuild Implementation
    // Build
    #endregion

    #region ICanFarm Implementation
    // Farm
    #endregion
}

You can pass in “generic” building and farming objects through the constructor of your class. That’s where composition comes in.

As other posters have mentioned a component architecture could be the solution to this problem.

class component // Some generic base component structure
{
  void update() {} // With an empty update function
} 

In this case extend the update function to implement whatever functionality the NPC should have.

class build : component
{
  override void update()
  { 
    // Check if the right object is selected, resources, etc
  }
}

Iterating a component container and updating each component allows the specific functionality of each component to be applied.

class npc
{
  void update()
  {
    foreach(component c in components)
      c.update();
  }

  list<component> components;
}

As each type of object is wanted you could use some form of the factory pattern to construct the individual types you wanted.

npc worker;
worker.add_component<build>();
worker.add_component<walk>();
worker.add_component<attack>();

I have always run into problems as the components get more and more complex. Keeping component complexity low (one responsibility) can help alleviate that problem.

If you define interfaces like ICanBuild then your game system has to inspect every NPC by type, which is typically frowned upon in OOP. For example: if (npc is ICanBuild).

You’re better off with:

interface INPC
{
    bool CanBuild { get; }
    void Build(...);
    bool CanFarm { get; }
    void Farm(...);
    ... etc.
}

Then:

class Worker : INPC
{
    private readonly IBuildStrategy buildStrategy;
    public Worker(IBuildStrategy buildStrategy)
    {
        this.buildStrategy = buildStrategy;
    }

    public bool CanBuild { get { return true; } }
    public void Build(...)
    {
        this.buildStrategy.Build(...);
    }
}

…or of course you could use a number of different architectures, like some kind of domain specific language in the form of a fluent interface for defining different types of NPCs, etc., where you build NPC types by combining different behaviors:

var workerType = NPC.Builder
    .Builds(new WorkerBuildBehavior())
    .Farms(new WorkerFarmBehavior())
    .Build();

var workerFactory = new NPCFactory(workerType);

var worker = workerFactory.Build();

The NPC builder could implement a DefaultWalkBehavior that could be overridden in the case of an NPC that flies but can’t walk, etc.

I’d put all the abilities in separate classes that inherit from Ability. Then in the unit type class have a list of abilities and other stuff like attack, defence, max health etc. Also have a unit class that has current health, location, etc. and has unit type as a member variable.

Define all unit types in a config file or a database, rather than hard coding it.

Then the level designer can easily adjust the abilities and stats of unit types without recompiling the game, and also people can write mods for the game.