Approach to having very many slightly different objects

Question

I'm currently working on implementing some form of the game Arkham Horror, and I'm starting to struggle with the vast amount of unique items and events in the game. For example, there are dozens of location events in the game, each of which has a more or less unique implementation. So my reaction would be to solve this with OOP, define a class for all events, and subclass/interface as needed. I've ended up defining classes for objects which will only ever have one instance, leading to over a hundred almost empty classes except for an overridden method.

The methods that I'm overriding are also increasing generic: revealLocationEvent: has 20+ different implementations because some reward players, some kill players, some cause the entire game to change state dependent on many variables, some trigger user interaction required events (on a separate UI thread or with an event queue + loop game state machine), some cause the event deck to be reshuffled and drawn from, and some just do nothing.

I can't do any sort of dynamic programming in Objective-C, so I can't inject functionality on the fly, which would be my obvious solution.

I was wondering what sort of approach you'd take so solve this issue. I also conceptualized a few other solutions, but they all seem more fragile than the next (having gigantic switch-cases inside the non-overridden function based on eventID, etc)

Answer 1

I don't know much about Objective-C but in all languages that support OOP, instance variables are a thing. You can store all kinds of properties in them and the class methods can take them into account to determine what kind of logic to execute.

So for your classes that only ever have one instance, make those into a class that is differentiated between type by instance variables. Here's some pseudocode to explain what I mean:

enum Action is (KillPlayer, ChangeState, NewEvent, Shuffle, Noop);

class Event
{
    Action revealAction;
    int actionArgument;

    function revealLocationEvent()
    {
        switch (this.revealAction)
        {
            case Action.KillPlayer:
                //kill the player
                break;
            case Action.ChangeState:
                //change the state to this.ActionArgument
                break;
            case Action.NewEvent:
                //create your new event
                break;
            case Action.Shuffle:
                //shuffle event deck
                break;
            case Action.Noop:
                //do nothing
        }
    }
}

I don't necessarily think it's bad to have many classes defined by short code files, but your mileage may vary. If you want to condense, something like this could be a solution.

Answer 2

In Objective-C or Swift, instead of creating one class after the other, have a single class with block properties / closure properties that you set when you create an instance. That's a widely used design pattern.

If you think it's not object oriented, complain to Apple about it. That's how you use notifications nowadays, for example.