0

I am currently working on a Roguelike where I have multiple different event queues(in the form of vectors), that handle multiple different event categories. Or rather, different game objects have their own private event queues.

Within the map tile data, I have a special trigger structure that activates when the player (or anything else) enters the tile. This tile structure provides data for generating an event flag, which then needs to placed onto the appropriate event queue.

The tile structure is as follows:

struct tile{
  int t_type;
  trigger t_dgram;

  vector<actor*> occupied;
  vector<item*> loot;
public:
  void trigger_tile(int ns, int we, );
};

The trigger structure itself can hold information for determining which queue is the appropriate one, but it's infeasible to hold pointers to all possible event queues for every tile in the map, particularly as I'm having maps dynamically generate terrain on the fly for infinite maps.

So the question is twofold: Would it be a good idea to cast a vector to a void pointer when calling the function:

void tile :: trigger_tile(int ns, int we, void *queue_ob);

The tile object itself will be able to determine the correct queue vector type and dereference the void pointer using the trigger t_dgram member variable, but is this a good idea? Is there some danger to this that I'm not aware of?

How would you personally suggest I achieve a similar effect?

Thank you for your time.

Druid
  • 133
  • 3
  • 12
  • 1
    It would not be possible to have a single event queue, where the actual event can be of different types? `struct Event {}; struct ActorEvent : public Event {}; ...`. And then store everything in a single `std::queue events`. This might be orthogonal for how you are planning to use them, however. – pingul Jul 27 '17 at 15:11
  • @pingul I had thought of that, actually. The main reason for not going that route was that many events caused entities to have to query other objects and wait for the results of additional processing. Having a single queue would then cause too much of a performance hit, sadly. Also, the servicing of different flags often needs to be handled by different objects with different access permissions, and having a single handler class ended up causing flexibility problems. :'D – Druid Jul 27 '17 at 16:33

2 Answers2

1

The "trigger" sounds like a class to me.

struct Trigger {
    virtual void triggeredOn(tile *tile) = 0;
}

Then tile has a pointer to its trigger:

struct tile{
  ...
  ...
  Trigger *trigger;
  void trigger_tile(int ns, int we, ){trigger.triggeredOn(this)};
};

Now classes derived from Trigger can hold pointers to any queues or even do something that does not involve queues.

0

So the question is twofold: Would it be a good idea to cast a vector to a void pointer when calling the function:

No, that does not sound right. Perhaps you meant to cast a pointer the vector to a void*, which will be OK as long as the downstream function that uses the void* casts is back to the vector pointer before accessing the elements of the vector.

R Sahu
  • 204,454
  • 14
  • 159
  • 270