I'm the author of a real-time pausable RPG. To answer your basic question, "Do I have to do all that stuff?" Yes, you do. In fact, I think you simplified; for an attack, my code runs three timers. One for a character preparing to attack, but not yet attacking, who should display a fighting animation. Second, when the character actually is attacking, to display the attacking animation. And third, when the character is recovering from his attack, displaying a recover animation (i.e. moving his sword back from the extended position to the ready position). Real-time is complicated!

Now, how to handle it in code? For your action class, I have a similar set of classes. However, I subclass depending on the particular action. So "attack with a weapon" in one subclass, "cast a spell" is another, etc. Is something like that possible in your architecture? If so, you should be able to avoid having one mega-action class. I actually have one giant class that handles running all the actions through a switch statement. I'm not proud of this architecture, but there are not that many types of actions, so I live with it, and it works fine. You can probably do better than that, though, if you are writing code from scratch, by moving some or all of the action-running code into the sub-classes.

Hope that helps a little,

Geoff

You might look into creating an interface for your attack items and implement this in your derived classes. This would then allow separation of the data structures and game logic of how they work but still allow you to store them in a simple data structure.

For example if we have an interface defined like:

interface iAttackable
{
    void Attack();
}

Then we could define a sword and spell class like this:

public class Sword : iAttackable
{
    public void Attack()
    {
        //...Do some logic in the attack
    }
}

public class Spell : iAttackable
{
    public void Attack()
    {
        //...Do some logic in the attack
    }
}

This way now you don't have to do a check on an object to see how to perform a specific attack. Abstracting it this way now allows for different logic to be handled by the unique class. You may need to add parameters to the interface in order to share objects between class but this information would be something you will need to figure out in your design. Now then back to the interface and now that we have defined the usage in two classes we could write code like:

//....Update method definition skipped
iAttackable attackItem = new Sword(); // Or this could very well be "new Spell();"
attackItem.Attack();

Because the attackItem is a generic interface class we can store either the Spell class or the Sword class in this variable. With this you can now even stack different kind of attacks so if a player wanted to use a sword and a spell they could without bloating your code just create a data structure to manage it. Having a generic enough way to access different types of classes can be beneficial in a complex system. One class can also implement multiple interfaces which then can allow you to blend different features generically into one class. For example you may need to do something special on the spell being cast during the update process. You can use type casting to these specific interfaces and then test if the cast worked before your proceed.

This is just one different approach that could help solve your design problem. Try a couple of different ideas and see how it works best for your design.